Hi all,
I know there was a discussion in year 2006, but I think it's time to bring this to the agenda again.
At the moment the design of PGV is full of tables. I know they are easy to implement, but I also know they are inflexible for different themes.
Technology in browsers and the functionality of Javascript in manipulation of objects has changed a lot.
Would it not be the time now to think about a state of the art design with divs and without tables?
I'm looking forward to your opinions.
Veit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is one of the real advantages of divs. The order in the html source may not match with that one displayed after aplying a css. Many sites use this mechanism for delivering content search engine friendly, first having the real content in the file and after that navigation, teaser and so on.
A good design with divs depends on the logic of content not on the logic of layout. The css and additionally perhaps javascript with css selectors is doing the full layout part.
So this is the theory. I know that the reality is something in between.
And yes, if there is a brider interest to do this step, I would volunteer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<I agree totally with the theory. I have just bad experiences trying to put it into practice. >>
I don't entirely agree with the theory to be honest. Just because something is new doesn't necessarily make it better :)
I find css-based layout to be well suited to static pages and fairly simple dynamic pages. But it is very much more difficult to implement for complex dynamic layouts. And it can be a lot of work getting layouts to work in all browsers on all platforms. Especially when you have a genealogy site where the visitors tend to be older and probably less likely to have the latest hardware and software. We need to be accommodating to Aunt Bertha and her Windows 98 PC with IE 5.5 or 6.
I too have had bad experiences trying to get rid of tables while keeping compatibility. I can't even count how many times I have done something that worked and looked great in Firefox and then found out that it is completely broken in IE. And I haven't even mentioned adding even more javascript to a project that already has a lot of javascript . . .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"done something that worked and looked great in Firefox and then found out that it is completely broken in IE"
Don't you mean "then found out that IE is completely broken" ? (GD&R)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-05-09
I've also been experimenting with this - and in my view its just not possible (totally) with a product with as many complex presentation design issues as PGV. Like stew, I have found the browser compatibility issues are huge.
I have successfully, almost, removed them from my welcome page, but once you start on the INDI pages it gets much harder. But then I'm prepared to be a bit hard on users (of my site) with the lesser known browsers, so tend to ignore Safari, Chrome, Opera, and any IE earlier than 6 (or sometimes even 7).
Longer term there is a much simpler solution. Latest browsers can produce tables using pure css3 tags like display: table; display: table-cell; and display: table-row. It is a much simpler process. The drawback is that IE can only use these tags in IE8. None of their earlier versions will display them. So until we can feel comfortable excluding users on anything up to IE7 from using PGV, its not practical.
I think there is a much more important step for PGV to take before removing tables - that is to remove ALL inline styling. Once this is in new an improved css files, then the transition to pure css becomes much more practical. It still won't be easy or quick, but I'd certainly volunteer to help with that one.
Thats not to say you shouldn't try Viet. I'd be interested to hear how you get on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One area that is being overlooked is that some of the code that can be changed from table based design to CSS based are already in templates in the themes.
One area that may benefit from theme CSS would be the indi boxes, and John started doing some work a while ago to make this very easy to change by actually moving some of the table templates into the themes. As far as I know, no one ever took advantage of this, and that is probably why more sections were not moved into templates. Within every theme, there is a templates directory that allow you to customize the large and small blocks on the indi page, as well as the person box template used on the indi page. Had this been used by anyone, the next one would probably been the indi box used in the charts. These chart indi boxes themselves are table based (the boxes themselves, and not the charts). You may want to start with these easy to customize sections, and if you find this goes well, the simplest way to go would be to publish a new theme that was light on tables. this would allow site owners to use a "table light" theme, or be more conservative and use the "legacy" table design without much of an impact on the actual code of the project. Depending on how successful this is, we can look at moving other portions of display code into theme templates.
Also note that the themes have a header.php that is ripe for CSS conversion.
It would be helpful to enumerate specifically what portions of PGV you want to move the tables off. The indil, family source etc lists are tables by design, and you probably are not referring to that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Beginning with removing the tables from the cloudy theme, I found that the menu has a lot of tables. I tried to make a hack for class_menu.php, generating this table code. After removing the tables from there the layout is broken. I checked this and found that for each menuitem there are two additional closing tags that make no problem in a table but kill a div based layout. There is some code around for rtl and ltr. For me the sense of this code is not completly clear, so perhaps someone can take a look on it.
With an unchanged theme removing all the table crap without additional divs the menu works fine already. I think this should be a good reason to remove these table code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi kiwi,
your comment about inline styles is probably right. Because of massive inline styles it is not possible in a lot of cases to control it by css definitions. They will be overwritten by the inline styles.
But if we work on a special topic it is practical to do both, remove the inline styles for this area and clean it from layout tables.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Veit, Greg,
One thing to keep in mind for the table removal from the menus are RTL issues. I think that John had them this way due to RTL issues. Meliza may have some additional information on this. Would it make sens to move the menue code to the themes? This would allow theme writers more flexibility with the menus, while leaving the option of a table based one for certain themes if RTL turned into an issues. If you have a URL and enable Hebrew I can have a look at it to see if they work for RTL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
kosherjava,
I have done some short testing with arabic also and found no issues with RTL.
But good to know, after the change is checked in others are able to do some more testing on it and if someone finds an issue, it can be rolled back or moved to the themes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-05-10
Another way to go with the menus already exists in PGV, thanks to some quiet work Greg did ages ago. I'm using it in a new theme I'm developing for my site. Its in the class_menus - a functions called getMenuAsList. It strips all the coding from the menu items so they can be used with css .
While you're doing this work, can I just make a plea to remember all the custom theme developers / users out there. Please document changes very carefully, so they can transfer changes easily to their own developments.
Viet, re RTL, from what I've seen (and no expertise) you should probably test RTL using Hebrew rather than Arabic. It appears to present more complications, judging by the amount of work Meliza regularly does to manage the presentation issues she faces. Just a perception.
One other comment on difficulties I have found, is in the layering required in many places. The 'z-index' tag is a key part of many pages and needs to be planned very carefully.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as RTL, I tested Viet's patch that Greg checked in, and it works well with Hebrew in IE8 and Firefox. I have no current way of testing it with IE6/7, though I may find a computer to test that tomorrow. As far as the getMenuAsList, it would be much more efficient if all the code was not first generated and than stripped off. Moving this to the theme dir, would allow theme authors to tweak this as much as they wanted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-05-10
KJ - re "it would be much more efficient if all the code was not first generated and than stripped off" - I totally agree.
Viet - a VERY minor issue with the menu change. The previous table structure included the code "<td valign=\"middle\">" which nicely aligned text with the center of their icon (where they are used, which depends on theme chosen). Moving to <div> loses this and goes to bottom-aligned (on most browsers), so it may be good to add it back in the css code. The appearance is different, (which will automatically concern some people), whether better or worse is of course a matter of taste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds like some good progress being made. Completely table-less design might not be feasible but simplifying some of the generated code to use divs is certainly a good idea.
The idea of moving menu design into the themes also sounds like a good idea. It would allow a lot more flexibility in design.
One thing to consider: It might not be possible to remove all inline styles. For instance it is fairly useful to be able to use inline styles in a module.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm afraid I don't see any value in inline styles. What is the practical or philosophical difference in specifying typography in inline CSS versus specifying it in HTML at the exact same location?
If there truly is some odd reason for the HTML generator to be specifying typography, you can still do it with CSS.
Example:
<span class="left bottom red big">some text</span> and some more text</p>
<div class="weird-font centered outdented">and a block of text</div>
CSS file:
#left
{
text-align: left;
}
#bottom
{
vertical-align: bottom;
}
/* define the others similarly */
#weird-font
{
font-family: blah-blah, yadda-yadda, .......;
/* Note that this lets me change my mind about the meaning of weird in a single location :-) */
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-05-10
Stew - but surely there's no reason a module can't use its own css files. Some already do. I would have to confess to using them a lot myself in custom modules etc - but I'm a lazy programmer! I really shouldn't <G>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All this sounds excellent from this user's point of view. Could I ask for one more thing?
Use classes for all data items within table cells and get rid of line breaks.
For example a typical cell looks like this:
<td class="optionbox wrap">
<span class="date">circa
<a href="calendar.php?cal=@%23DGREGORIAN@&
year=1851&month=&
day=&action=year">1851</a>
</span>
<span class="age"> (Age 22)
</span>
<a href="individual.php?pid=I4834&ged=family.ged">Jane JAMES</a>
-
<a href="family.php?famid=F3520"> [View Family (F3520)]</a>
<a href="placelist.php?action=show&
parent%5B0%5D=Australia&
parent%5B1%5D=South%20Australia&
parent%5B2%5D=Clare&
parent%5B3%5D=Saint%20Barnabas%20Church&
level=4"> Saint Barnabas Church, Clare, South Australia, Australia</a>
<br/>
<br/>
<br/>
<span class="label">Note: </span>
<span class="field">Some secondary sources show marriage date of 1 Jan 1859.</span>
<br/>
</td>
As you can see, some data items are enclosed by spans with classes and some are not. Also there are forced line breaks which the user can't negate.
Applying classes to all data items would enable the user to use css to determine line breaks, spacings and margins rather than being stuck with a rather ugly rendition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi kiwi,
thanks for the remark with the text position. I sent a patch for style.css to Greg for committing to svn for the cloudy theme. I have checked it with IE6, IE8, FF3 and GC. I have to check if it works with the other themes the same way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I know there was a discussion in year 2006, but I think it's time to bring this to the agenda again.
At the moment the design of PGV is full of tables. I know they are easy to implement, but I also know they are inflexible for different themes.
Technology in browsers and the functionality of Javascript in manipulation of objects has changed a lot.
Would it not be the time now to think about a state of the art design with divs and without tables?
I'm looking forward to your opinions.
Veit
If you want to volunteer for this task, then please do!
I keep looking at using divs and css, but always find that it is just too difficult/complicated.
For example, consider a table with one row and two columns:
<table><tr><td>one</td><td>two</td></tr></table>
This sort of thing that is frequently used to divide the screen into two areas, with "one" on the left and "two" on the right.
On a RTL langauge page, this automatically reverses the order of the columns, so that "one" is on the right and "two" is on the left.
If there's an easy way to do this with divs and css, I've yet to find it......
I think this is one of the real advantages of divs. The order in the html source may not match with that one displayed after aplying a css. Many sites use this mechanism for delivering content search engine friendly, first having the real content in the file and after that navigation, teaser and so on.
A good design with divs depends on the logic of content not on the logic of layout. The css and additionally perhaps javascript with css selectors is doing the full layout part.
So this is the theory. I know that the reality is something in between.
And yes, if there is a brider interest to do this step, I would volunteer.
I agree totally with the theory. I have just bad experiences trying to put it into practice.
<<I agree totally with the theory. I have just bad experiences trying to put it into practice. >>
I don't entirely agree with the theory to be honest. Just because something is new doesn't necessarily make it better :)
I find css-based layout to be well suited to static pages and fairly simple dynamic pages. But it is very much more difficult to implement for complex dynamic layouts. And it can be a lot of work getting layouts to work in all browsers on all platforms. Especially when you have a genealogy site where the visitors tend to be older and probably less likely to have the latest hardware and software. We need to be accommodating to Aunt Bertha and her Windows 98 PC with IE 5.5 or 6.
I too have had bad experiences trying to get rid of tables while keeping compatibility. I can't even count how many times I have done something that worked and looked great in Firefox and then found out that it is completely broken in IE. And I haven't even mentioned adding even more javascript to a project that already has a lot of javascript . . .
"done something that worked and looked great in Firefox and then found out that it is completely broken in IE"
Don't you mean "then found out that IE is completely broken" ? (GD&R)
I've also been experimenting with this - and in my view its just not possible (totally) with a product with as many complex presentation design issues as PGV. Like stew, I have found the browser compatibility issues are huge.
I have successfully, almost, removed them from my welcome page, but once you start on the INDI pages it gets much harder. But then I'm prepared to be a bit hard on users (of my site) with the lesser known browsers, so tend to ignore Safari, Chrome, Opera, and any IE earlier than 6 (or sometimes even 7).
Longer term there is a much simpler solution. Latest browsers can produce tables using pure css3 tags like display: table; display: table-cell; and display: table-row. It is a much simpler process. The drawback is that IE can only use these tags in IE8. None of their earlier versions will display them. So until we can feel comfortable excluding users on anything up to IE7 from using PGV, its not practical.
I think there is a much more important step for PGV to take before removing tables - that is to remove ALL inline styling. Once this is in new an improved css files, then the transition to pure css becomes much more practical. It still won't be easy or quick, but I'd certainly volunteer to help with that one.
Thats not to say you shouldn't try Viet. I'd be interested to hear how you get on.
For further explanation of css3 tables:
http://www.webdevelopmentbits.com/exploring-the-power-of-css3/
One area that is being overlooked is that some of the code that can be changed from table based design to CSS based are already in templates in the themes.
One area that may benefit from theme CSS would be the indi boxes, and John started doing some work a while ago to make this very easy to change by actually moving some of the table templates into the themes. As far as I know, no one ever took advantage of this, and that is probably why more sections were not moved into templates. Within every theme, there is a templates directory that allow you to customize the large and small blocks on the indi page, as well as the person box template used on the indi page. Had this been used by anyone, the next one would probably been the indi box used in the charts. These chart indi boxes themselves are table based (the boxes themselves, and not the charts). You may want to start with these easy to customize sections, and if you find this goes well, the simplest way to go would be to publish a new theme that was light on tables. this would allow site owners to use a "table light" theme, or be more conservative and use the "legacy" table design without much of an impact on the actual code of the project. Depending on how successful this is, we can look at moving other portions of display code into theme templates.
Also note that the themes have a header.php that is ripe for CSS conversion.
It would be helpful to enumerate specifically what portions of PGV you want to move the tables off. The indil, family source etc lists are tables by design, and you probably are not referring to that.
I think your suggestion is a very feasable way. I will start small with a template with reduced tables and we will see how it is going.
Beginning with removing the tables from the cloudy theme, I found that the menu has a lot of tables. I tried to make a hack for class_menu.php, generating this table code. After removing the tables from there the layout is broken. I checked this and found that for each menuitem there are two additional closing tags that make no problem in a table but kill a div based layout. There is some code around for rtl and ltr. For me the sense of this code is not completly clear, so perhaps someone can take a look on it.
With an unchanged theme removing all the table crap without additional divs the menu works fine already. I think this should be a good reason to remove these table code.
Cleaning my menu layout has removed 43 tables from each of my pages.
I think it's a good result for the first day.
I have tested with IE6, IE8, FF3 and Google Chrome. I have tested all included themes and found no impact from the hack.
Veit - sounds good.
If you want to send me a patch file, I'll submit it to SVN.
Hi kiwi,
your comment about inline styles is probably right. Because of massive inline styles it is not possible in a lot of cases to control it by css definitions. They will be overwritten by the inline styles.
But if we work on a special topic it is practical to do both, remove the inline styles for this area and clean it from layout tables.
Veit, Greg,
One thing to keep in mind for the table removal from the menus are RTL issues. I think that John had them this way due to RTL issues. Meliza may have some additional information on this. Would it make sens to move the menue code to the themes? This would allow theme writers more flexibility with the menus, while leaving the option of a table based one for certain themes if RTL turned into an issues. If you have a URL and enable Hebrew I can have a look at it to see if they work for RTL.
kosherjava,
I have done some short testing with arabic also and found no issues with RTL.
But good to know, after the change is checked in others are able to do some more testing on it and if someone finds an issue, it can be rolled back or moved to the themes.
Another way to go with the menus already exists in PGV, thanks to some quiet work Greg did ages ago. I'm using it in a new theme I'm developing for my site. Its in the class_menus - a functions called getMenuAsList. It strips all the coding from the menu items so they can be used with css .
While you're doing this work, can I just make a plea to remember all the custom theme developers / users out there. Please document changes very carefully, so they can transfer changes easily to their own developments.
Viet, re RTL, from what I've seen (and no expertise) you should probably test RTL using Hebrew rather than Arabic. It appears to present more complications, judging by the amount of work Meliza regularly does to manage the presentation issues she faces. Just a perception.
One other comment on difficulties I have found, is in the layering required in many places. The 'z-index' tag is a key part of many pages and needs to be planned very carefully.
As far as RTL, I tested Viet's patch that Greg checked in, and it works well with Hebrew in IE8 and Firefox. I have no current way of testing it with IE6/7, though I may find a computer to test that tomorrow. As far as the getMenuAsList, it would be much more efficient if all the code was not first generated and than stripped off. Moving this to the theme dir, would allow theme authors to tweak this as much as they wanted.
KJ - re "it would be much more efficient if all the code was not first generated and than stripped off" - I totally agree.
Viet - a VERY minor issue with the menu change. The previous table structure included the code "<td valign=\"middle\">" which nicely aligned text with the center of their icon (where they are used, which depends on theme chosen). Moving to <div> loses this and goes to bottom-aligned (on most browsers), so it may be good to add it back in the css code. The appearance is different, (which will automatically concern some people), whether better or worse is of course a matter of taste.
<<aligned text with the center of their icon>>
Well spotted - I hadn't noticed this. You're right, the place for this is the theme's css file.
Veit - FYI, kiwi_pgv runs a site www.pgvthemes.com. Whenever I make changes that will impact theme developers I post details there.
Sounds like some good progress being made. Completely table-less design might not be feasible but simplifying some of the generated code to use divs is certainly a good idea.
The idea of moving menu design into the themes also sounds like a good idea. It would allow a lot more flexibility in design.
One thing to consider: It might not be possible to remove all inline styles. For instance it is fairly useful to be able to use inline styles in a module.
I'm afraid I don't see any value in inline styles. What is the practical or philosophical difference in specifying typography in inline CSS versus specifying it in HTML at the exact same location?
If there truly is some odd reason for the HTML generator to be specifying typography, you can still do it with CSS.
Example:
<span class="left bottom red big">some text</span> and some more text</p>
<div class="weird-font centered outdented">and a block of text</div>
CSS file:
#left
{
text-align: left;
}
#bottom
{
vertical-align: bottom;
}
/* define the others similarly */
#weird-font
{
font-family: blah-blah, yadda-yadda, .......;
/* Note that this lets me change my mind about the meaning of weird in a single location :-) */
}
Stew - but surely there's no reason a module can't use its own css files. Some already do. I would have to confess to using them a lot myself in custom modules etc - but I'm a lazy programmer! I really shouldn't <G>
All this sounds excellent from this user's point of view. Could I ask for one more thing?
Use classes for all data items within table cells and get rid of line breaks.
For example a typical cell looks like this:
<td class="optionbox wrap">
<span class="date">circa
<a href="calendar.php?cal=@%23DGREGORIAN@&
year=1851&month=&
day=&action=year">1851</a>
</span>
<span class="age"> (Age 22)
</span>
<a href="individual.php?pid=I4834&ged=family.ged">Jane JAMES</a>
-
<a href="family.php?famid=F3520"> [View Family (F3520)]</a>
<a href="placelist.php?action=show&
parent%5B0%5D=Australia&
parent%5B1%5D=South%20Australia&
parent%5B2%5D=Clare&
parent%5B3%5D=Saint%20Barnabas%20Church&
level=4"> Saint Barnabas Church, Clare, South Australia, Australia</a>
<br/>
<br/>
<br/>
<span class="label">Note: </span>
<span class="field">Some secondary sources show marriage date of 1 Jan 1859.</span>
<br/>
</td>
As you can see, some data items are enclosed by spans with classes and some are not. Also there are forced line breaks which the user can't negate.
Applying classes to all data items would enable the user to use css to determine line breaks, spacings and margins rather than being stuck with a rather ugly rendition.
Hi kiwi,
thanks for the remark with the text position. I sent a patch for style.css to Greg for committing to svn for the cloudy theme. I have checked it with IE6, IE8, FF3 and GC. I have to check if it works with the other themes the same way.