Re: [SM-DEVEL] Templates + CSS (Was: Templating and plugins (Was: CVS: squirrelmail ChangeLog, 1.763, 1.764))

[Paul L. <pa...@sq...>]

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.

Will send a heads-up to cvs list too (PS- that was one of the lost
messages...).  Rest of the changes are not related specifically to
css, just templating system in general.



> 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
>