Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Better CSS
imho, this argument is eclipsed by the fact the CSS is stored BASE-64 encoded in the database which a) bloats its size, and b) adds time to the CSS download process as it is decoded.
rvm_css is a stock component of all my sites because I like serving stuff from the file system: it’s piggin’ quick in comparison. For some, this isn’t a big deal so to leave it in the DB is fine and having it in two places at once on a stock install — as jakob pointed out — might just make things unnecessarily complicated.
As for the css.php, I’m with ruud here; it’s gotta be quicker to load that tiny bit of php than the whole of index.php, which probably helps to compensate for the fact the CSS has to be decoded from the database ;-) But perhaps the way the URL is presented could be better out of the box, I don’t know. Again, there are options if you wish to present a unified URL scheme to your visitors (gbp_permanent_links or .htaccess) and I get your argument for why it should be presented like that by default. The question is whether it can be unpicked in the core from all the legacy code… and whether it needs to be. My guess is that since it’s not been addressed by now, the chances are there’s a reason why it’s the way it is.
Of course, it could be that nobody’s really paid much attention to that corner of the code before!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Better CSS
Well if your using rvm_css you’ve got two copies anyway :/ I dunno I can’t see a problem with it being stored in the DB and then allowing other people to cache it in a folder from the admin preferences pane if you desire (in other words its not on by default) therefore it wont be in two places on stock default, ONLY after the user has chosen to do so.
But for me this makes perfect sense the DB version is the main one and then the cached version is the one that could be loaded if so desired. I just feel this should all be built in. And legacy systems should work fine with it, as nothing is really changing, your still using the same TXP tags, so ALL sites will still work the same, all coming from the DB, but those who want the cache version too, that will just work the same as rvm_css but natively, so when the option is set to YES the <txp:css /> will serve it from the cache file instead of from the DB!
Also coming back to the CSS.php file, are you not already using the index.php file for the page rendering and articles? so why not have the CSS use it as well?
~ Cameron
Offline
Re: Better CSS
driz wrote:
Well if your using rvm_css you’ve got two copies anyway
Yep, my choice though and I’m a geek so I don’t mind :-)
I would very much like to have the option of CSS in the file system and/or in the DB natively. Treating the file system version like a cache makes sense to me as well. But again: I’m a geek not a designer so this sort of thing is on my radar. Might not be for people of a non-cody mindset?
Any road, will have to see what’s possible. I’d rather see if it’s possible to demangle the BASE64 thing first so plugin authors can offer simpler CSS tools (for example, searching them from smd_where_used without going through the coding pain of treating it differently to all other admin-side data!) Probably more important than what a URL looks like!
btw, xPattern’s first patch was to essentialy roll rvm_css into the core.
coming back to the CSS.php file, are you not already using the index.php file for the page rendering and articles? so why not have the CSS use it as well?
*shrug* only been in the job a week. There’s a whoooole lot of code to grok yet…
Last edited by Bloke (2009-07-26 22:04:24)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Better CSS
One of your main objections was that css.php was inside the textpattern directory. It no longer is (well, for compatibility reasons, but that’s not an issue for you).
So the only other thing is the URL. Do visitors really care what URL is used for serving CSS? I don’t think so. Let’s focus on things that really need to be improved, before dealing with stuff like this ;)
Offline
Re: Better CSS
no the visitor will not care. but then again the visitor will also not care your even using Textpattern.
BUT the guy behind the scenes cares (well i do) about the efficiency and consistency of files with a website.
~ Cameron
Offline
Re: Better CSS
Bloke wrote:
I would very much like to have the option of CSS in the file system and/or in the DB natively. Treating the file system version like a cache makes sense to me as well. But again: I’m a geek not a designer so this sort of thing is on my radar. Might not be for people of a non-cody mindset?
I’m a designer first, geek second. I’ve launched a whole lot of TXP sites using static CSS files in the file-system, and one or two (very simple designs) that used Textpattern’s CSS tab. Speaking for myself, it never made sense to keep CSS in the database, and I’d be interested in knowing if I’m missing out on the benefits. To me, it seems that the file system offers a lot. In addition to the speed differences already mentioned:
- Static files can be kept in version control.
- Static files are easier to edit in specialized authoring tools. The SASS compiler I’m using to style a TXP-based discussion site I’m working on offers way more than I would ever reasonably expect from Textpattern (shorthand, variables/mix-ins, compression).
- Static files give you absolute control over URL structure.
A few of these things are possible without abandoning Textpattern’s CSS suport as I have, to wit: I use cnk_versioning to keep all my templates in the file system during development. It automatically imports pages, forms, and styles with each refresh when the site’s production status is not Live. One could easily get the best of both worlds using this plugin.
This isn’t a complaint about Textpattern at all. I don’t look to Textpattern to be a top-notch CSS-editing tool— it’s awesome enough without that. Were I publishing stylesheets as downloads like David DeSandro (BBHSHTCL), maybe I would lean more on Textpattern for this. But for now, I’m content with keeping Textpattern agile and powerful with other kinds of content.
Last edited by johnstephens (2009-08-09 01:50:41)
Offline
#19 2009-08-09 19:39:39
- TheEric
- Plugin Author
- From: Wyoming
- Registered: 2004-09-17
- Posts: 566
Re: Better CSS
In thinking about it, I’m realizing that there is no specific advantage to having the CSS maintained within the DB. Accessing flat files directly would be marginally faster than by the dB method. Perhaps the CSS editing tool can be revised so that it loads/saves it as a flat file within a CSS specific directory? The only drawback to that would be that the CSS directory would need to be writable, and that can create some security issues.
Oh, and just to clarify, I am by no means agreeing with Driz. THAT would never happen.
Last edited by TheEric (2009-08-09 19:41:04)
Offline
Re: Better CSS
It’s not a security issue. The images/files directory is also writable.
Accessing static CSS files from a visitor perspective is not marginally faster. The speed difference is huge! That’s why I wrote rvm_css.
From an admin side point of view, moving from DB to flat file storage makes no sense at all. There is no noticeable speed difference there.
Offline
#21 2009-08-10 02:06:42
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Better CSS
Writing to files only would also be one more location you have to backup. At least when you’ve got the static+db copy, you only have to backup the db to have the style info saved.
Offline
Re: Better CSS
TheEric wrote:
Oh, and just to clarify, I am by no means agreeing with Driz. THAT would never happen.
It’s times like this when I wish this board had proper smileys!
;0)
Keith
Blyth, Northumberland, England
Capture The Moment
Offline
Re: Better CSS
Mary wrote:
Writing to files only would also be one more location you have to backup. At least when you’ve got the static+db copy, you only have to backup the db to have the style info saved.
Backup/portability. Definitely a benefit imho.
Plus, if I have to tweak css when I’m not at my own computer, it’s very simple when the css is in the database.
Offline
Re: Better CSS
I think Textpattern has it right. The CSS belongs in the database. The way to get the best of both worlds is to integrate full-page static caching into the core, and cache CSS files along with content pages. The result would be that the CSS is backed up and transportable along with the rest of the database, but is served at full static file speed (after the initial request).
Offline