From: pdontthink <pdo...@ya...> - 2006-10-04 13:13:27
|
On 9/27/06, Paul Lesniewski <pa...@sq...> wrote: > Also, didn't want to lose this idea: > > > 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. Rest of the changes are not related specifically to css, just templating system in general. > On 9/26/06, Paul Lesniewski <pa...@sq...> wrote: > > > OK, lets keep this simple. I propose we scrap the current handling of > > > > Heh, I wish t12n of styles was simple... :) > > > > > 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. > > > > How is style.php different than that now? Ah, you are proposing the > > removal of setting $color to the stylesheet template? Aside from that > > and the extra sheets that are loaded at the very bottom, I think this > > is not any different, no? > > > > Also, what about keeping a mechanism that lets stylesheet "overrides" > > be loaded at the bottom of this file (or somewhere else that comes > > after the default template sheets are loaded)? That would be for some > > kind of extra "color theme" sheets selected by the user, whether or > > not that is actually implemented at this time... I guess this question > > is addressed more below. > > > > > 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. > > > > If we load all css files in the template set's css dir, then this is > > not necessary -- UNLESS we are specifically intending to provide a > > fallback to the default.css from the default template set (if > > found)...?? What style definitions are we trying to accomodate with > > this file? Can we say those style definitions should go in > > stylesheet.tpl instead...: > > > > I also realized style.php *EXPECTS* to have a stylesheet.tpl file in > > the template set, so that's another template requirement, however, it > > is once again one that can fall back on the default template set, > > which is great, but we don't have a fallback if the default template > > set doesn't have one. I'm wondering if we should copy the one you > > made for the "default" template set into SM_PATH/css and the Template > > class knows to get it from there in the case that it was not found > > (*ONLY* for stylesheet.tpl)...? > > > > > 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. ;-) > > > > We can instead just put them in SM_PATH/templates/<template > > name>/css/alternates/ and do the rest automatically. In display > > options: if ($oTemplate->hasAlternateStyles()) { > > show_options_widget($oTemplate->getAlternateStylesList(); } Then the > > user prefs get a new setting for alternate sheet to be used, but > > question is if that setting is *specific to that template set* or just > > a singular value: it's nice to think about storing alternate sheets > > for each template set, but the user prefs can get junked up a little > > bit. I think that's OK. Then in style.php at the bottom, we'd look > > at that pref setting (hand it to the template object, which can do > > most of the work) and load the new (alternate) sheet so it overrides > > styles as needed. No? > > > > > 4) Do away with $color themes altogether. We can convert them to > > > stylesheets that reside in SM_PATH/templates/default{_advanced}/css/. > > > > Yeah. This means uprooting a lot of what is in stylesheet.tpl now. > > Put them in SM_PATH/templates/default{_advanced}/css/alternates and we > > can try out the proposed system I outlined above...? > > > > > 5) SM_PATH/css/ becomes a repository for user-provided stylesheets. > > > > What's there now? Hrm, looks like one stylesheet that provides a set > > of defaults for what is otherwise found in stylesheet.tpl? We should > > do something with this (either decide that we will specifically use it > > as a default (always load it first, or have the template class load it > > if stylesheet.tpl is not found) or get rid of it. > > > > > 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. > > > > I'm not sure we need or want this, especially if we have alternate > > stylesheets available in each template set. Only advantage is that > > each template author doesn't have to recode their own alternate > > sheets, which can be nice, especially if they have done a good job of > > using our standardized style names. > > > > Other issue is that do we mix this style selection in the display > > prefs with the selection of the alternates provided inside the > > template set itself? If we don't, then there are TWO "theme" widgets > > on the display prefs page, which is confusing at best. > > > > > 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/. > > > > Alright, that's fine, if a bit convoluted. My proposed idea of > > keeping the alternate sheet selection in the user prefs attached to > > the template set gets washed down the drain, and actually creates a > > problem: if the user selects an alternate that is provided by the > > template set but then changes their template set selection, then that > > alternate sheet can no longer be used (well I suppose it could, but > > that gets really convoluted IMO). This seems a bit ugly to me. > > > > > 7) Stylesheets are loaded in the following order: First: style.php. > > > > Why? Shouldn't all the template's standard css files be linked first > > and style.php be last, since it contains user overrides for font > > sizing and whatnot? This way, style.php can also be where we look at > > user prefs (since we are already doing that in style.php for font > > sizes, etc) and load up any selected alternate sheets, which should > > also be loaded last so they override everything else? > > > > (Addendum: after reading below, I think the step you missed that comes > > first is the loading of all the css files found in the template set's > > css dir. If we render the alternate sheets outside of style.php then > > style.php can in fact come 2nd) > > > > > Second: tempaltes/TEMPLATE_DIR/css/defaults.css. > > > > See above -- what is the need for this file at all? If we do need it, > > maybe it should be loaded before style.php because it might contain > > some default font sizes or things like that. > > > > > Third: the > > > stylesheet selected by the user in the Display Preferences in item #6, > > > if one has been selected. > > > > OK, you are suggesting we divorce loading alternate sheets from > > style.php, so page_header.php asks the Template object directly to > > take care of this. That's not a bad idea, at least for clarity in > > page_header.php > > > > > 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. ;-) > > > > ok. If default is a SM-provided sheet, it should be in the SM_PATH > > tree I think. > > > > > 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 > > > > So you are aksing authors to put ALL their default stying into one > > file called default.css and the other files are to be treated as > > alternates for the user to choose from? I guess we can run with that, > > but letting the author create multiple sheets and dump them in the > > template/css dir gives them more flexibility and ability to organize > > their styles better. I would vote for the latter. > > > > ; SM_PATH/css/ would be the home of user provided > > > stylesheets that may/may not work with a particular template set. > > > > mmmm, I think template-independent sheets is a powerful concept, > > although there could be issues with this. > > > > > 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. > > > > Well, *both* are user prefs in the end. :) But I think you are > > right, because then the user will be less confused when their font > > selections don't seem to be working. > > > > > 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. > > > > Don't follow. Post-processing would only be parsing out the strings > > and translating them. The styles are unaffected I think. > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |