Hitting the limit for length of css input

ax · 2012-07-10 21:44:14

When trying to use the bootstrap.css from the Twitter Bootstrap framework, it turns out that it does not fit into the Textpattern’s css table. This is because Textpattern uses the TEXT data type, which is limited to 65535 characters (2^16). In contrast, the data type MEDIUMTEXT, which is used for body in the texpattern table, would allow for a maximum length of 16777215 characters (2^24). Perhaps TEXT should be changed to MEDIUMTEXT for css?

philwareham · 2012-07-10 22:15:59

I’d strongly recommend not putting a large CSS file into the database, it’ll run like a dog in there.

In fact, I’d personally never put any CSS into the MySQL database, always better to serve it as flat files. Reasons have been discussed many times, like here.

joebaich · 2012-07-10 22:39:43

I quite like to use rvm_css especially now that one can write LESS files to the database and have them compile them to flat CSS files. I haven’t had ax’s size limit problem with Twitter Bootstrap, probably because I don’t use all the modules but I may well be getting close. For us, ease of routine backup (CRON Job) is an added bonus of having LESS/CSS in the database. Therefore I quite like the notion of up-gunning the appropriate mySQL datatype. It’s not as if CSS is generally going to get any lighter soon. So a +1 from me.

ax · 2012-07-10 23:01:04

joebaich wrote:

I quite like to use rvm_css especially now that one can write LESS files to the database and have them compile them to flat CSS files.

Didn’t know that, and then I could be using Twitter Bootstrap’s LESS modules instead. Should be much easier to work with than the huge bootstrap.css file.

Bloke · 2012-07-10 23:12:20

joebaich wrote:

I quite like the notion of up-gunning the appropriate mySQL datatype.

If CSS framework-like files are generally getting bigger then we’ll be nudged towards increasing it anyway. Once you start hitting the table limit, rvm_css will dutifully serve the truncated file at filesystemspeed :-)

Then the only way round it is to:

do what Phil suggests and bypass the DB entirely, using cnk_versioning or just manually uploading CSS files
do what Joe suggests and use LESS + rvm_css
split the files into smaller hunks and serve multiple sheets (which makes PageSpeed and the Internet complain)

Isn’t 65Kb quite big for a CSS file? I’d argue the rules need simplifying if that’s the case. But then, what do I know; with MQ and stuff, maybe large stylesheets are the norm. I’ll go with whatever the people at the sharp end of web design tell me is right, because I don’t know any better!

Last edited by Bloke (2012-07-10 23:14:24)

Gocom · 2012-07-11 00:31:18

Bloke wrote:

Isn’t 65Kb quite big for a CSS file?

I would call that quite small. Even for a very simple website (a single column blog or a product page) it’s rather hard to go below 15 KBs or so even if you merge every and single rule possible to the point where the thing is impressively hard to read.

Especially with responsive, fluid layout and transitions, the files are big even on smaller websites. On a web application we normally would talk about 100-600 KB of CSS. For instance Beanstalks’ global styles alone are over 200 KB.

Not that any serious development team would use the database for their CSS. Even mentioned the idea would make most laugh.

If I could decide the fate of that beloved CSS panel, I would love to see it to go. First threaten it with @deprecated note in source and then boom, year later, that thing would be gone for good.

Last edited by Gocom (2012-07-11 00:35:26)

philwareham · 2012-07-11 05:48:00

As gocom says, 65k is actually quite a small limit for CSS files these days, even with minification. Whilst I’m also in favour of killing the CSS panel (or more specifically having core support for serving flat files of pages and partials) we should up the limit on that database table.

maniqui · 2012-07-11 15:02:48

Bloke wrote:

do what Phil suggests and bypass the DB entirely, using cnk_versioning (…)

I don’t think cnk_versioning would be helpful here, as it precisely “sucks” the CSS file back to the DB (thus, eventually hitting the field length limit). That said, user could simply have cnk_versioning ignoring CSS files and done.

Gocom wrote:

If I could decide the fate of that beloved CSS panel, I would love to see it to go. First threaten it with @deprecated note in source and then boom, year later, that thing would be gone for good.

In the very beginning (circa 2004/2005), I used to love some of those DB-centric features of TXP (“moving your website is just copying the DB & you are almost done”). Not so much now.
At that time, there were a popping up a lot of CMSs and some of this DB-centric features were attractive for newcomers to the CMS & general web-development world. Also, TXP was just a little project at that time, with a target audience not as defined as now, which, imho, current main audience¹ of TXP is both front/back-end web developers like enjoy crafting content-centric websites.

Then, one begins to learn a little more about best/good/bad practices, and finds all this css.php and page templates editable only via browser a bit a not-so-good thing.

Bottom line: I’m all for beginning to deprecate stuff that doesn’t promote good/modern practices on web development, and focusing on features that could empower TXP’s main audience of web developers that enjoy crafting better (I repeat: imho). Or something like that :)

¹ https://twitter.com/cococorazonloco/status/216007826349371392

Edit: Ops! This “tweets-are-now-embedded” feature also embeds tweets that are just linked to some text (i.e. "check this tweet":http://link-to-tweet… mmmmmpfh).

Last edited by maniqui (2012-07-11 15:05:37)

colak · 2012-07-11 16:10:06

philwareham wrote:

I’d strongly recommend not putting a large CSS file into the database, it’ll run like a dog in there.

I agree but I also like the idea of having everything stored in the db too. This makes sense when working on one of the mobile devices or away from your computer. As such it would be wonderful if rvm_css and spf_js became part of the core.

Dragondz · 2012-07-11 16:12:13

Sorry folks, but i still use css on the db, (more than 30 website) it make easy to make changes, and if the performance are crucial i can use rvm_css, but i continue tweeking the website online.

I think different people has different working method, i dont thing that one method is better than another!

Cheers

Bloke · 2012-07-11 16:16:00

fwiw I still use the CSS editor too. Love it. Use Dev Toolbar to tweak the site live, copy, paste, save, done. Beats having to edit offline and then FTP the file up (yeah yeah, the editor could do that for me, but it makes working with files slow). I always use rvm_css to serve CSS to visitors though, because it’s faster.

I’m all for keeping cached copies of stuff (from core) on the filesystem so we can take advantage of file system speeds. But keeping stuff in the DB is just too handy to lose when it comes to backup time.

Last edited by Bloke (2012-07-11 16:17:33)

maniqui · 2012-07-11 16:53:22

Dragondz wrote:

I think different people has different working method, i dont thing that one method is better than another!

Yes, I agree with you, and I don’t even totally agree with myself (that is, with the post I made above) :)
I was just thinking loud about making TXP more friendly with, well, different working methods.
cnk_versioning functionality (moving stuff from DB to filesystem and then back to DB) is really helpful for teamwork workflows that use VCSs like Git/Mercurial/SVN.
In the future, I’d love to see some TXP features going on that direction, allowing more development workflows.

Textpattern CMS

Textpattern CMS support forum

#1 2012-07-10 21:44:14

Hitting the limit for length of css input

#2 2012-07-10 22:15:59

Re: Hitting the limit for length of css input

#3 2012-07-10 22:39:43

Re: Hitting the limit for length of css input

#4 2012-07-10 23:01:04

Re: Hitting the limit for length of css input

#5 2012-07-10 23:12:20

Re: Hitting the limit for length of css input

#6 2012-07-11 00:31:18

Re: Hitting the limit for length of css input

#7 2012-07-11 05:48:00

Re: Hitting the limit for length of css input

#8 2012-07-11 15:02:48

Re: Hitting the limit for length of css input

#9 2012-07-11 16:10:06

Re: Hitting the limit for length of css input

#10 2012-07-11 16:12:13

Re: Hitting the limit for length of css input

#11 2012-07-11 16:16:00

Re: Hitting the limit for length of css input

#12 2012-07-11 16:53:22

Re: Hitting the limit for length of css input

Board footer