Separate directories? You hadn't said (or implied) that they were this separated.
That certainly means that they would each have their own CSS file, so there is no concern there. Technically, generating an in-file <style> area is going to be slightly easier than writing out to a separate CSS file, so it may simply win on that basis. But there are two other reasons that reinforce this: (1) If you hold user style information in the database but also generate a CSS file at the time the user changes the look, you end up with a potential for things getting out of step. It's similar to using an un-normalised database. (2) There may be a temptation later to offer the customisation facilities to the individual end-users, rather than the Blog owners. This would be much simpler to do if there was no CSS file involved. Now, all of this doesn't mean that you should get rid of an external CSS file completely. Remember that the styles cascade and later styles add to the effects of earlier styles. Therefore, everything that the Blog owner cannot change could easily be out in a CSS file and only the things that he/she can change would be sent with the file. There are several reasons for breaking it this way: (a) The CSS file can be left with a reasonably long time-to-live in the user's cache, so won't be sent each time. The HTML file will be smaller. Transfer times will be less. (b) Generation of the <style> area in the HTML file will be a bit simpler. (c) You are never in any doubt remembering what you've allowed the Blog owner to control - if it's still in the CSS file, then it isn't under owner control. Yet another option (and I don't know whether it'd be a good one in this case or not, but it's certainly worth thinking about) is to have a "default" value for each of the customisable options - which is something you already have, of course - and store a "default" status in the database if the user hasn't changed a particular setting. Then you would have an external CSS file that includes the default, and generate style overrides for only those settings that the user has changed. A benefit of this approach is that it makes it a bit easier to offer a "reset all to default" option, and "default" options for each of the customisable settings. There are attractions towards this approach and also concerns that it breaks the KISS principal too violently. Have fun. Dave S ----- Original Message ----- From: Gary Broyhill To: [email protected] Sent: Friday, February 25, 2005 1:12 AM Subject: RE: [ASP] CSS changing on the fly I think you're right about using the <style> area at the top of the file, although these 6 Blogs are in six separate directories, and the CSS would control all the pages in those directories only. Thanks for answering my questions and allowing me to do some thinking out loud. Gary [Non-text portions of this message have been removed] --------------------------------------------------------------------- Home : http://groups.yahoo.com/group/active-server-pages --------------------------------------------------------------------- Post : [email protected] Subscribe : [EMAIL PROTECTED] Unsubscribe: [EMAIL PROTECTED] --------------------------------------------------------------------- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/active-server-pages/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
