Alan, thank you for your comments, my replies inline below. I will probably contact you off list at some point, and see where your work and my work can meet up, as well as the work of some of the others you mentioned. On Nov 15, 2008, at 12:53 PM, Alan in Toronto wrote: > On Fri, November 14, 2008 10:21 pm, Paul Lesniewski wrote: >> On Fri, Nov 14, 2008 at 5:01 PM, Scott Haneda >> <talklists@xxxxxxxxxx> wrote: >>> On Nov 13, 2008, at 7:31 AM, Alan in Toronto wrote: >>>> On Wed, November 12, 2008 8:31 pm, Scott Haneda wrote: >>>>> Currently I would like to improve on the issue in this image: >>>>> http://www.newgeo.com/web/misc/172910-sm.png >>>>> There is plenty of room to show more of the name, how can I >>>>> accomplish >>>>> this? >>>>> >>>>> As seen in this image, there is a grey area to the right, this >>>>> can be >>>>> larger at times, is there any way to get full expansion of the >>>>> table: >>>>> http://www.newgeo.com/web/misc/17316-sm2.png [...] >>> The skins that come with SM, largely, to me, look a lot like >>> terminal >>> coloring gone bad :) > > They're not really what I would call skins. They are just some > colour variations > based on the very limited ability of 1.4.x code to be styled. This > is part of the > problem I'm raising. > >> CSS can be not-so-benign sometimes I think, but that's beside the >> point. > > I don't know what youo're referring to. CSS is mature, well > understood and, when > used correctly, creates a site that can be fully styled or can > degrade gracefully to > an unstyled state and still be fully usable. Unlike javascript, CSS > does not require > different code for different browsers and can not cause browsers to > crash or hang. You just described my first step, delete all refernces to any CSS, look into the template files, find any hard codes style="foo:x y z " stuff embedded in the php, and get rid of that. When I have the code down to what I would call the "cragslist" of displays, then I can start working on it. >>> I can not simply start working on the CSS. This is >>> not a case like CSS Zen Garden, where every chunk of html is >>> referenced by a CSS class and you can go to town. If you disable >>> all >>> CSS in SM, it does not degrade down to a text only display, but >>> seems >>> to be very table driven, and the frames, those may or may not need >>> to >>> go, depending on which side of the fence you are on with that >>> debate. >> >> You *can* start working on the CSS. Create a skin based on the >> default one for starters and try tweaking the css therein. > > What is possible with the current SM code is quite limited, which is > why the best > looking SM implementations have been achieved by modifying the SM > code. That's why > I'm suggesting that we first correct all the errors and deprecated > code in SM's > HTML, and also add some class and ID attributes. That will give us a > clean, > addressable base on which to create various CSS layouts/designs. > > We would want to create some SM standards, by creating a set of > class names and IDs > that developers would then use. We should also create HTML coding > guidelines to > ensure future releases and modifications follow both Standards and > good practice. > Again, Paul knows that I have great respect for what the SM team > have achieved: it's > a terrific application and makes good use of PHP. I want us to now > bring SM's HTML > up to the same standard of excellence as its PHP. So far, I think this is more applicable to the older branch of SM. What I am seeing now, is that there has been a good deal of thought put into this issue, and at least in the devel version I pulled from svn, things are looking pretty good, once I get a grasp of it all. >> I have wanted to do this for a long time. I see some hurdles. As >> the >> above poster mentioned, there are not the best of ways to hook into >> the core code. I can not simply start working on the CSS. This is >> not a case like CSS Zen Garden, where every chunk of html is >> referenced by a CSS class and you can go to town. If you disable all >> CSS in SM, it does not degrade down to a text only display, but seems >> to be very table driven, and the frames, those may or may not need to >> go, depending on which side of the fence you are on with that debate. > > There are at least two developers, other than NutsMail, who have > made altered > versions of SM. I was in contact with one of them earlier this year, > and he has done > an impressive job of cleaning up SM's HTML and using good CSS to > style it. So, much > of the work has been done, and we need to bring folks like that into > the SM project > rather than forcing them to do their own thing outside the project. Can you point me to examples of the designs? Even screenshots would be great, I just want to see where they are going and how much it is the same, or different, than what I have in mind. > The template concept for SM seems to me to be reinventing the wheel. > There is > already a well-established, well-understood and standards-compliant > means for > achieving layout and design of web applications: CSS. Rather than > invest development > energy in an SM-specific template system, we should work together to > make SM > standards-compliant and able to be altered via CSS. We can then > benefit from the > vast knowledge already existing of how to layout and style CSS > sites. I am happy to > help, as I design only standards-compliant CSS sites. I would also > contact others > with similar goals for SM, some of whom have already done good work > on modifying SM > for their own needs. I am not so sure this can really work, which I touched on in my other email. There are two places I can think of in which you simply can not edit a css file to change how SM works. If SM generates html for the message display that is like this: div for headers div for subject div for main body of email div for footers So that is a simple case, and has a logical flow to it, but I am locked into it. What if I wanted to put a second copy of the subject at the bottom of the email, and perhaps, move the headers to the upper right of the window. At that point, I can no longer use logical flow of html, or even floats, I have to start looking at absolute positioning, and z-index etc. Now, if in a template file, I have something where there is bare bones minimal php code, and I can move that around inside that template file, I will never have to touch the core code, just the inner template file. This is exactly how WordPress works, and phpBB as well as a number of the other php based forums. The php forums that do not have a lot of skin/theme offerings, are always the ones that take a different approach to the above. > I'm tired of seeing web hosts and organizations remove or avoid > SquirrelMail because > their users find it ugly. My own host removed SM, in favour of other > IMAP > alternatives, based on user feedback. I was one of the few who wrote > in support of > SM, but as I install my own anyway the outcome did not really affect > me. I share your exact sentiment here, which is why I am wanting to work on this. My frustration comes from the ignorance of so many ISP's I know that travel in the same circles as me on other mail lists. I rarely hear about SM's performance, or relative ease of install. I just hear that it is ugly, therefore, it can not be good. I have seen many an ISP use a inferior product, one I know, in simple tests, flat out fails to adhere to some very basic IMAP RFC requirements. They still insist it is "better", and to be honest, I question if they even installed SM, and are just going based on demo's they have seen online. Seems "the pretty" can go a long ways to get something traction these days. With SM, we can have pretty and function and performance. It will get there, it may take me some time, but it will get there. Thanks for sharing your comments in this thread. > The work I'm recommending is not huge, and will lead to great > improvement in the > look and feel and customization possibilities for SM, and could lead > to a greatly > increased user base. I hope we can agree to do this. I agree, the scope of work is not huge at all, it is more tedious IMHO, sometimes you just have to do that to get where you want to go, but it gets easier once the framework is solid and in place. Thanks again. -- Scott ------------------------------------------------------------------------- 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
