CSS Revamp in Jojo

CSS Revamp in Jojo, a forum discussion on Jojo CMS. Join us for more discussions on CSS Revamp in Jojo on our General Discussion forum.

Back to Forum Index : Back to General Discussion   RSS
Harvey

Core Developer

Harvey

6 Mar 2011
Posts: 327

Hi all, just a heads up.

I'm making some changes to the way Jojo handles CSS files, and probably everything here applies to javascript as well. I have always thought the CSS handling in Jojo was pretty excellent compared with other CMSs I have used. So I'd like to extend that further.

Here's what I'm working on...

CSS files in smalller chunks

Firstly, there are going to be new API options for adding CSS into styles.css - currently I'm finding style.css is getting massive, especially on design-heavy sites. So instead (if you like), the theme can contain the following...

style.css
sidebar.css
font.css
menu.css
some_jquery_plugin.css

Basically you sort your CSS into logical divisions, then add a call in api.php that consolidates everything into styles.css

Jojo::mergeCSS('styles', array('sidebar.css', 'font.css', 'menu.css', 'some_jquery_plugin.css'));
Note the exact format of this API call may change.

The only purpose of this is to let you break CSS into logical blocks while developing. Some will be quite happy with a jurassic CSS file, so nothing will change if you are happy as is.

IE Conditional comments

I'm also looking at ways to make IE conditional comments easier to work with. Currently most sites I do have a file called ie6.css and ie7.css with conditional comments manually added into customhead.tpl. This works, but could be better.
Basically, plugins and themes should be able to create a file called lte_IE_7.css or something to that effect, and the required code for the conditional comment is automatically added into the header. I want plugins to start getting smarter about adding the required IE hacks.

Mobile stylesheets for iPhone / Android

Android and iPhone (and probably Windows mobile 7) ignore media="handheld" attributes in CSS tags, because they think they are fully-fledged browsers. Instead, they seem to respond to media="only screen and (max-device-width: 480px)".
But I'd really like to start implementing better support for these at a plugin level, as they aren't the same as proper browsers. I find that it's about an hour's work to add the required 'fixes' to a smallish site to make it look good on an iPhone/Android. Essentially a lot of this is replacing fixed pixel widths with "width:100%" on wrapper divs, and hiding big banner images, sidebar crap, and other elements that aren't needed.

I'm no expert in this field, so I'd like to start a discussion on how we should handle this. I'd like to head towards plugins coming with an iPhone / Android stylesheet, that makes your site look cool on all pages if you go to the trouble of adding an iPhone/Android stylesheet to your theme.

My gut feeling is that we want to avoid browser-sniffing and having to serve a separate m.domain.com version of the site, although we don't want to rule that out.

Do people agree that media="only screen and (max-device-width: 480px)" is a good way to target these devices, or is there a better method we should be employing? I like that this method won't target iPads and their Android counterparts, as the screens are big enough to warrant the standard website experience.

Dynamic CSS

Something that's been on my mind for a while. Wouldn't it be cool to be able to include variables or PHP code in CSS files. I'm mostly thinking of letting you store a colour in a variable somewhere eg $light_blue instead of hard-coding the same hex value in lots of places.
I'm still quite undecided on this one, but currently I'm thinking of letting you add sidebar.css.php into the CSS folder, and simply parsing/eval'ing the file as PHP instead of plain text. It would need to have acess to Jojo options and the database connection, so you can define your variables in the UI somewhere. Remember that CSS files are cached, so dymanic doesn't mean that the content can change regularly. It's more about making it easier to maintain consistency across the CSS.

Refreshing CSS

Browsers suck at obeying HTTP cache headers. I won't go on, but the only reliable way I know of to get browsers to refresh a CSS file when you want them to is to give it a different URL (ie add a random querystring variable).
I'd like to add a querystring variable to the styles.css declaration in Jojo, and have a managed way of updating that variable. This will likely be a form of detection whenever styles.css changes - so everytime you update any CSS file, the browser update it's link from styles.css?v=123 to styles.css?v=124.

There are cache issues to consider here, so this will likely need to be bound to an event somehow - possibly after a CTRL-F5 request or setup being run which I would think would happen after every CSS change.

There should also be a button for forcing a CSS refresh manually, possibly on the admin homepage.
Rick Rick

7 Mar 2011
Posts: 336

I agree wholeheartedly, and have some feedback if you're keen...

Splitting the CSS into logical files

Great idea. I initially thought "why can't we just auto-include all the files in css/ except for the special (print, lt_ie_7, etc) ones?"... but then we can't specify order. Your idea works well.

Actually, could this be done with a filter? This would allow a lot more versatility in the order etc. Could be that each plugin adds it's css file paths (including the plugin name) to the content array.

A way of adding css files to the head without duplication would be good too. Say two plugins use a third party plugin, there's no sense including that third party plugin's stylesheet in the customhead.tpl of both plugins. Not as big of an issue, but I've come across it.

The more that we can get happening automatically, the better.

IE Conditional Comments

A way of auto-including these files would be great. I think the best thing about this would be that you'd have a single conditional statement (for each applicable IE version) that would wrap every plugins files. Or they could get merged, even.

Side note: I've wondered about having a single jQuery onready call that pulls in all applicable code from the plugins. Useful? Redundant?

Mobile Stylesheets

Your idea is great, smartphone specific stylesheets are a great idea. But that's only hiding the extra elements. If we also detect these visitors at the PHP level, we can avoid parsing these elements unnecessarily. If done purely via stylesheets, it'd be nice to have a button to trigger a parent class high up or something to bring everything back. I hate being "stuck" in mobile view.

Dynamic CSS

For a while I've thought about adding a hook in there so I can implement LessPHP as a plugin. If this supported server-side includes, it'd solve your first issue too.

Refreshing CSS

This one gets me a lot... changes a week after a site goes live and I end up having to add a new stylesheet line. What I like about Jojo is the clean URLs, eg no version number on the asset files. But I've thought about adding a timestamp to it (triggered by clearing the cache in the admin area, or CTRL+F5 or dedicated button as you suggested) and that would trigger the added version/timestamp to the url. But this would revert back to the plain old "styles.css" link once the cache time had passed... eventually leaving us with clean URLs again.


A lot of this is rambling, but most of it I've been thinking about for a while... mostly the dynamic CSS and CSS/JS file refresh.
Jaijaz Jaijaz

9 Mar 2011
Posts: 215

Time to reply to this one. Thanks for starting this discussion.

Before I get into each item, has the stripping of @font-face rules been fixed yet. I haven't had time to test but this will effect all CSS3 @ rules moving forward. I as yet still don't have SVN commit fixed if anyone reading can fix.

CSS files in smalller chunks

This is a great idea. Though my preferred method for doing it would be along the lines of the $_provides['pluginClasses'] that gets specified in api.php. Something like $_provides['stylesFiles'].

IE Conditional comments

I think this could be done in a simpler way. $_provides['stylesFiles_lte_IE_8'] for example means that if you wanted to have seperate ie menu files to content files you could.

Mobile stylesheets for iPhone / Android

I have been playing with the idea since our meetup back in October of a way to use a technic similar to what Mike posted here to detect and then serve the appropriate files. This would mean that there was no need to redirect to a different subdomain and it would be seemless from the users perspective. There would of course need to be a flag that can be set in response to a user click that enforces the full site.

Dynamic CSS

I'm with Rick. I have had a very small look at Less CSS and wondered if that concept could be pulled into Jojo. My simple hack was going to be to implement something similar to how we handle javascript tpl files.

Refreshing CSS

This has been an interesting one for me recently. As an experiment I have been developing with Safari. Safari on Mac doesn't have a way to refresh cache except for refreshing a page after it as already downloaded. This seems to work well with CSS refreshes but doesn't refresh the common.js.

It seems to me there are two different instances of where this is needed. First during build/development. For this I was thinking of a flag in the config.php file, like the debug but without the message where nothing is cached and the v= could be a unix timestamp of the moment the page is served. This would mean that it is always changing. The second time is if you make a small change after go live. For this, correct me if I'm wrong but running setup will clear the cache so it is only to reset the file name for the browsers that won't behave. This could be a unix timestamp of the last time setup was run. I think having this on the common.js would be a good idea too.

I agree with Rick about clean URLs but unfortunately ISP's seem to have got a lot more aggressive in caching so might be necessary.


My 2 cents anyway.
If you not living on the edge you taking up too much space.
tom

Developer

tom

9 Mar 2011
Posts: 379

The font-face stripping has been fixed in the current svn.

What doesn't work however is the Boilerplate approach of adding media css at the end of a single common style sheet - the format for those declarations
@media print {
/* style sheet for print goes here */
}
is too wacky for the optimiser at the moment and it strips them out.
It would be good if the separate style sheets for print.css etc could be optionally added in automagically at the end of styles.css using that format (rather than calling them separately in the head).

Boilerplate also allows for conditionals within the main stlyes.css by including the browser as a class on the html tag, so your styles can be overriden by
.ie6 #header {
Although that generally means your css won't be W3C valid, I find it a cleaner approach, and easier to keep track of, than separate files for each browser.
gravidar

2 Apr 2011
Posts: 2

Great to see css is still under development.

I can't find anything in the docs to say how to disable the css sanitisation, is this possible?

JoJo is removing rules that I want to keep so while combining css files into 1 stylesheet is great the sanitisation is a little heavy handed for my taste and I haven't got time to rework a stylesheet that works already.

Cheers
Harvey

Core Developer

Harvey

3 Apr 2011
Posts: 327

I don't know that there is a way to disable the built-in sanitisation / optimisation. One thing you could do is stick the CSS files in the htdocs folder and serve them directly (outside of Jojo).

Generally the optimisation is a good thing - just some CSS hacks won't work when the comments etc are stripped out.
gravidar

3 Apr 2011
Posts: 2

Great, thanks Harvey.
Was hoping there might be an option but as you've suggested I'm now serving from the web root using customhead.tpl
It was indeed a browser hack as auto-generated for Spry menus that was giving me the issue.
Cheers.
Back to Forum Index : Back to General Discussion   RSS
You must be logged in to post a reply



You need to Register or Log In before posting on these forums.