On Sat, Nov 15, 2008 at 12:53 PM, Alan in Toronto <Alantoronto@xxxxxxxxxxxxxxx> 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 >>>> > >>>> It's absolutely possible, and could be adjusted easily by users, if >>>> we could >>>> encourage those developers who write core and plugins code to use >>>> better HTML, >>>> without fixed dimensions in elements like tables, and to make >>>> liberal use of class >>>> and ID attributes. Then the whole SquirrelMail UI would be more >>>> flexibile and >>>> adaptable and could be adjusted or even transformed by use of CSS >>>> (Cascading Style >>>> Sheets). >>>> >>>> Right now the SM team writes good PHP, but the HTML is "old school" >>>> and infexible. >>>> Without much work, the excellent base that they've built could be >>>> improved by >>>> cleaning up its HTML and adding attributes that can be targetted by >>>> CSS. >>>> SquirrelMail could look much better and be much more customizable, >>>> without a lot of >>>> work. > >>> 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. He was referring to the look and feel that comes with SM by default (and primarily of 1.5.2), not the color themes of 1.4.x. No matter how many times you raise issues with 1.4.x, I don't see that there will be any interface related tweaks made to it. Stable software stays the way it is beside small changes and bug fixes. >> 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. The point was that CSS can be part of a security hacker's toolset. No one is making arguments against CSS. You shouldn't equate that we won't make changes to our stable branch with a judgment against CSS. Instead, you should look at how CSS is being used in 1.5.2 and contribute toward its further development. >>> For lack of a better word, SM needs a >>> 'web 2.0' skin, maybe not so heavy on the AJAX junk, but something >>> that gives this book a good cover. > >>> 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. This thread is about 1.5.2. You should stop referencing your opinions about 1.4.x in this thread, which is only confusing matters. Your comments are not relevant to the discussion at hand. > 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. Please review 1.5.2 before you make further suggestions. >>> SM needs to drop down to a html validated, compliant, text only >>> version when the CSS calls are removed. If that is done, then anyone >>> can simply grep out all the CSS classes, and go design crazy with it. >>> I think there would be more relevant designs if this burden was removed. > > Exactly! > >> 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. > > We don't need to go as far as using AJAX at this point. As I say, just correcting > the errors in SM's HTML and adding classes and IDs to enable CSS styling will offer > huge benefits. Once SM is able to be styled, then CSS developers can really create > many layouts and designs for SM. > > 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 You are speaking without understanding what a template is or how it is used. Please stop this until you have an understanding of what it is you are criticising. > 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. > > The work I speak of, correcting errors and removing deprecated methods in the > existing HTML, and providing a better base for styling via CSS, would not make 1.4.x > unstable. It would not harm 1.4.x's "stable" status any more than the ongoing > revisions and improvements to 1.4.x as each new release appears. I don't agree and don't think you have an understanding of the code and what is meant when we say we won't make large changes to our stable codebase. > 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. > > 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. All efforts as far as we are concerned need to be directed at 1.5.x. Your advocacy has always been appreciated, but please understand what codebase this conversation is in regards to and only make criticisms until you have some understanding of what it does. ------------------------------------------------------------------------- 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
