> > >>>>> Also, if you can please report the style name for the table issue > >>>>> you > >>>>> identified (and even the fix if you find it), I will put the fix > >>>>> into > >>>>> the default skins. > >>>> > >>>> > >>>> <td class="col_date" > >>> > >>> Why col_date? The whole table is what isn't stretched out, right? > >> > >> I thought you wanted me to report the name of the css class I could > >> not find referenced in any css files. I am no longer trying to > >> resolve the issue of a table not fitting into the correct width, > >> which > >> is easily solved by setting the second inner table to 100% the same > >> as > >> the outer table. > > > > You didn't specify that you found a fix for the problem you first > > reported. If you can indicate where you made this change, I'd like to > > commit it to SVN. Please do tell. > > I think it is premature now that you have explained a few things to > me. Rather than me supplying patches willy nilly here and there, I > want to get a better grasp of what is going on with the code and the > theme systems. If there was a problem rendering a table like that in the default template, the fix should be made there, not just in another skin. It would be best if you can just explain what table needed the additional 100% width. > I can provide much better patches, and patches that do more and take > less of your time in code review, if I take the time to learn a more > complete idea of the entire system. > > >> Ay any rate, eventually, if this is to remain as a table, I would > >> need > >> access to every td in every table. I think I can manage this with > >> the > >> new template based theme system, it looks a lot like phpBB, which I > >> have hacked around in a good deal. > > > > I think ultimately the idea was to leave the simple table layout and > > allow skin developers to go table-less if they felt like it. But I'd > > be interested to hear if you have another proposal for the basic > > default template. > > To table or not to table. I have been thinking about this in the > background a bit. The table layout provides a logical way of viewing > web based email. It fails on a few fronts, mainly in that the refresh > parameter must be set for the left frame. Not sure why having data refresh has anything to do with using tables in your layout. Moreover, there is no "refresh parameter" in a table frame - it's all done with JavaScript IIRC, but I guess it could be done with a META tag as well. Not really related to tables anyhow. > I think still having that > is a good idea, but rather then meta refresh, using a little > javascript in that area may give a better user experience. It may not > be worth it for the fact it can fail if you do not want to use JS. > > Certainly, there are many actions users perform in SM, that can be > more intelligent about that refresh. Any action in the main window > (child) certainly can send a refresh off to the left frame (child) > giving it a much higher chance of being up to date. See the Folder Sync plugin. I don't see what any of this has to do with using tables. > Then, you can simply not enable an auto-refresh, which saves some > performance cycles to the server, as well as that blink of page redraw > on the screen. The folder list refresh is needed because it pings the IMAP server to see if new mail has arrived. It's not always something to do with an action by the user in SM. > The clock is another one, in that it is only as up to date as a > refresh, The "clock" you see is supposed to document the time that the last mail check was done, and it works just fine for that. > and adding in the seconds parameter, is rather pointless, as > it will always be out of date. There are plenty of preferences that > set the time zone and offset, so that can easily be a real time clock. IIRC there is/was a "javascript clock" plugin if you want a real clock. Please be sure to *ask* about things you don't understand rather than make analyses based on incorrect assumptions. > The main consideration for me with the left/right table issue, is > design driven. You are confusing tables with frames. This was supposed to be a conversation about tables, but you're talking about frames, which will always stay in SM by default. There are some advanced ways that template designers can use a one-frame layout, but that's for another time. > If you want to make a truly well designed theme, the > left and right frames should, in my opinion, be able to blend into > each other. This could be tricky since the width of the left frame is > variable. I do think, with some thought, a background image could be > put into place, that seamlessly blends the two together, and no matter > the left frame width, the users experience would be that the page is > one cohesive unit. > > I will tackle this when I get there, but I just wanted to put it out > there, as it is the first area I will look at once I get up to speed > on the system. > > >> Ok, I can do that as well, that is a simple find and replace as long > >> as I am careful. I think the new template/theme/skin system will > >> make > >> it a non issue anyway, as I should be able to rename anything I > >> desire > >> to whatever I desire, as soon as /css and the other little bits are > >> compartmentalized into the template system. > > > > Well, but it makes A LOT of sense to keep a consistent list of > > commonly used base styles. Forcing every skin developer to create a > > whole slew of styles of their own is overkill and won't be very > > inviting to more casual skin developers. > > Right, good point. And further, each css class, id etc, needs to be > documented along with the name. Helping document the style/class names would be very very appreciated. > A simple short one or two sentence > description of what it controls, where it can be found and where it is > in use, will go a long way. There is no way my brain can remember > this as I go, so as I always do, I will be taking notes as I go for my > own purposes. If these end up becoming useful, you can add them to > the docs when I feel they are complete. Perhaps they could become > part of a theme development guide that should one day exist. Exactly. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
