From: pdontthink <pdo...@ya...> - 2006-10-04 13:16:49
|
On 10/2/06, Paul Lesniewski <pa...@sq...> wrote: > Last repost--- > > On 10/2/06, Paul Lesniewski <pa...@sq...> wrote: > > Another re-post > > > > On 10/2/06, Paul Lesniewski <pa...@sq...> wrote: > > > All, > > > > > > According to gmane's archive, this thread only has two posts. I am > > > re-posting my three or four missing posts again now in hopes that they > > > make it through this time. First post was mostly a top-post note: > > > > > > > Currently, the cacheing doens't work > > > > very well because it looks at the mtime of stylesheet.tpl for the > > > > time. This is a problem because if the user changes $color themes, > > > > the stylesheet is still cached because the mtime on stylesheet.tpl > > > > isn't affected by this change. > > > > > > Yeah, not sure what to do with setting mtimes for what boils down to a > > > user setting. I suppose we could store an mtime in the user prefs > > > that is set to the actual file's mtime by default but is updated to > > > the date and time that the user made the prefs change when they change > > > themes. That might work well, but would we want to compare the file's > > > own mtime to see if it is more recent than what is in the user prefs > > > and update the user prefs mtime value before sending the date to the > > > browser? > > > > > > I did try to put some notes about this into style.php > > > > As for all of the following, I still consider the conversation very > > much open, however I am wanting to commit the work I've done to date > > so maybe it's easier to put into context and people can see what has > > been done before the changes get too far out of hand (they are already > > extensive). > > > > Thus, I am committing my templating class re-writes, which also touch > > several pages throughout SM. As for the stylesheets implementation, > > my temporary implementation (completely subject to change pending this > > thread's resolution) is as follows: > > > > 0. There is a new "prototype_header" (in lieu of "html_header" in case > > it's not HTML being spit out) template that functions/page_header.php > > uses in the dispalyHtmlHeader() function. All of the following are > > assigned to that template and then it is displayed, so no more echo > > commands in displayHtmlHeader(). > > > > 1. Links spit out to all .css files in templates/<template name>/css > > dir EXCEPT rtl.css > > > > 2. Placeholder (although there are some unsolved issues for loading > > prefs in displayHtmlHeader() function) for spitting out links to style > > override selected in user prefs (should be full path relative to > > SM_PATH and should come from selection of template list gathered from > > proposed templates/<template name>/css/alternates and > > SM_PATH/css/alternates) > > > > 3. style.php link then added (uses stylesheet.tpl, but if that is not > > found in current template, nor the default template, fallback is to > > load SM_PATH/css/default.css); no other stylesheets are included at > > the bottom of style.css > > > > 4. The template class is then asked specifically to add the rtl.css > > link (first looks for rtl.css in current template, then in default > > template, otherwise SM_PATH/css/rtl.css is the fallback) > > > > NOTE: default.css from SM core had style definitions that were missing > > from default template so I copied it wholesale into that template's > > css dir. I think all these default (and non) styles need to probably > > be cleaned up and refactored and re-categorized > > > > ALSO NOTE: that there is an issue with the stylesheet > > "stylesheet_advanced" from the default_advanced template set: because > > to date that has been a .tpl file with some dynamically generated > > elements (for RTL/LTR and some $color theming), there is no one place > > to fit it except to refactor it into the other css files or > > stylesheet.tpl or something. I think this might need a bit more > > thought. > > All css links could be to style.php, which renders the css file as a > template. This way pure css files just get rendered as is (although > it's a bit less efficient than linking to the file itself, and creates > caching problems (that I hope would be addressable with same ideas > I've already expressed)), but they can also contain dynamic elements > filled in by the templating engine that depend on RTL/LTR, theme and > font settings in the user prefs. style.php would need to be > generalized a bit more to accomodate this, but it's one idea that > might work. Steve/others... after a disasterous mailing list boondoggle that I'm not even sure is over, I'm not sure where we all stand on this CSS plan. Steve, I see you deduced some of my points above by looking at code. Some points were missed. Where do we stand now? I implemented Alexandros' great template inheritance idea and everything seemed to work wonderful... although when I merged with your changes, I lost all styles when I log in, no matter what skin I am using. I am hoping that only has to do with the fact that you reorganized where certain stylesheets are placed, which I think is sorely needing some clarification. I'm also not seeing my org_title in the title bar, either, so I assume the recent changes to webmail.tpl caused that? I'll look for other important postings that may have been lost, but I think this conversation needs to get back on track. (although now that I've gotten these posts up, I will be gone for a long weekend.... :) ) - Paul > > > On 9/26/06, Steve Brown <sbr...@gm...> wrote: > > > > Sorry if you get this twice, I was having mail problems earlier tonight... > > > > > > > > On 9/25/06, Paul Lesniewski <pa...@sq...> wrote: > > > > > > > > <snip> > > > > > > > > OK, lets keep this simple. I propose we scrap the current handling of > > > > stylesheets and do the following to solve all of this: > > > > > > > > 1) Modify style.php so that it only sets font preferences, e.g. set > > > > and size. These preferences are set in the Display Preferences. > > > > 2) If it exists, always load templates/TEMPLATE_DIR/css/default.css. > > > > I would expect to always have this file, but its possible we won't. > > > > 3) Add an optional template config variable for additional stylesheets > > > > that are provided by the template set. These sheets would also be > > > > located in templates/TEMPLATE_DIR/css/. They could be used to provide > > > > alternate color themes provided by the author, e.g. "My Blue Template" > > > > and "My Red Template", etc. This is a new feature and something I > > > > just thought of, so don't get confused. ;-) > > > > 4) Do away with $color themes altogether. We can convert them to > > > > stylesheets that reside in SM_PATH/templates/default{_advanced}/css/. > > > > 5) SM_PATH/css/ becomes a repository for user-provided stylesheets. > > > > These stylesheets are selectable in the Display Preferences (keep > > > > reading). Yes, not all stylesheets will be 100% compatible with all > > > > templates, but I don't think its our concern to worry about that. > > > > We may need to create a dir for each css sheet to give it a name and > > > > provide some images and a few other things, but I can elaborate on > > > > this later. > > > > 6) The widget in the Display Prefernces that is currently used for > > > > $color themes is replaced with a widget for selecting *optional* > > > > stylesheets. This widget lists all of the optional stylesheets > > > > provided by the template in item #3 above, as well as all of the > > > > stylesheets in SM_PATH/css/. > > > > 7) Stylesheets are loaded in the following order: First: style.php. > > > > Second: tempaltes/TEMPLATE_DIR/css/defaults.css. Third: the > > > > stylesheet selected by the user in the Display Preferences in item #6, > > > > if one has been selected. Fourth: depending on the language > > > > selection, SM_PATH/templates/TEMPLATE_DIR/css/rtl.css for RTL > > > > languages. If this sheet does not exist, we load > > > > SM_PATH/templates/rtl.css, which is the RTL CSS for default templates. > > > > I don't think this should be in SM_PATH/css/ because it is not a full > > > > stylsheet. Maybe stick it in SM_PATH/i18n/css/? Location TBD. ;-) > > > > > > > > I think this solves most of the issues we have with CSS. > > > > Philosophically, I would see templates/TEMPLATE_DIR/css/ as the home > > > > of stylesheets that are known by the author(s) to work well with this > > > > template set; SM_PATH/css/ would be the home of user provided > > > > stylesheets that may/may not work with a particular template set. > > > > > > > > So we are talking about at most four stylesheets being loaded at any > > > > point in time. Its possible that style.php would be loaded after the > > > > selected stylesheet so that the user prefs always win. I also don't > > > > know if we could do RTL conversions in a post-processed i18n system > > > > because it would require some potentially *very* difficult stream > > > > modification after the fact. > > > > > > > > Lets shoot some holes in this plan and see where the gaps are. > > > > > > > > Steve > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |