caching problem with mobile css

[learning_brain]

www.donbur.co.uk

This site has a php mobile detection script which activates a different architecture and css for mobile devices... nothing new there other than I'm not using the css selector statements.

When viewed on a mobile, you get an option to switch to normal full screen mode (classic view). This is simply a form which sends a $_GET variable back to the same page.

In addition, on every page, I also keep sessions.

So... if no session... start session

if isset($_GET['mobilepref']) then $_SESSION['mobilepref'] = $_GET['mobilepref'].... see where I'm headed?

So for every page visited afterwards, this session variable should be stored (mobilepref happens to be "fullscreen").

Therefore, if the detection script shows its a mobile and $_SESSION['mobilepref'] != "fullscreen" it will show the fullscreen version...

MY PROBLEM is that if you go to the index page for example on a mobile (tablet or otherwise), it seems to store the mobile layout in cache (or any other page you view first). If you then go to another page and then click (view classic), this works for that page, but if you return to the index page, it doesn't show the fullscreen version... ??? (unless you refresh)

How can I resolve this without having to force no-cache?

I don't particularly want to force a no-cache as there is quite a bit of content in the header/footer.

Any ideas?

 

[cybrax]

You could use a Javascript making an Ajax call server-side (fired by the page onload event trigger) to get the session value and swap the CSS on the fly inside the clients browser. The downside of this is however is two-fold..

a: it's a bloody awful hack to implement
b: Android 2.2 has issues passing session values on the URL and it don't like ajax requests either. I mention this as there's an awful lot of those budget smartphones out there like the HTC Wildfire floating around the UK. Despite being less than two years old they will not upgrade to the newer O/S automatically.

Ideally this sort of thing is best handled by the classical browser 'Cookie' but most folk have them blocked by default and the EU regulations are not helping matters. Personally I would try to force the issue with the visitor, if they want to set preferences then they accept a cookie. The alternative is to get sneaky and insert an image based cookie as this won't set any warnings off in the browser. (Google: EverCookie Samy K)

 

[learning_brain]

You could use a Javascript making an Ajax call server-side (fired by the page onload event trigger) to get the session value and swap the CSS on the fly inside the clients browser.

My mobile detection script is server-side, using user-agent info so I don't really need any AJAX work to change content based on what's going on client-side. The entire page architecture and css are different before page load but on some tablets, It seems to cache all pages browsed before choosing the fullscreen option... bizarre.

a: it's a bloody awful hack to implement

*shudders*

b: Android 2.2 has issues passing session values on the URL and it don't like ajax requests either. I mention this as there's an awful lot of those budget smartphones out there like the HTC Wildfire floating around the UK. Despite being less than two years old they will not upgrade to the newer O/S automatically.

Hmmm - is the Wildfire still running on Froyo? - we've had gingerbread and ICS since then! I'm not sure it's a problem with passing the variable in the session. I've done some test scripts to echo back the $_SESSION['screenpref'] variable and despite having the right file on the server, I don't get the test output on the mobiles I've tested. This would indicate that it's caching the whole page and css. Only when I refresh does it get rid of the problem.

Ideally this sort of thing is best handled by the classical browser 'Cookie' but most folk have them blocked by default and the EU regulations are not helping matters. Personally I would try to force the issue with the visitor, if they want to set preferences then they accept a cookie. The alternative is to get sneaky and insert an image based cookie as this won't set any warnings off in the browser. (Google: EverCookie Samy K)

I'm not so hot on using cookies for this sort of thing - I'll read up and get back to you.

Thank you

Richard

 

[essellar]

I'd be tempted to dispense with the whole thing, design for responsive and let @media queries handle the differences. The trend now is to give little useful information in the user_agent string (a good decision if you ask me, since it prevents the "mobile site redirect" that breaks search and deep links), so a server-side solution isn't going to be very long-lived in any case. Mobile (with indeterminate screen size at an indeterminate pixel resolution) is the new mainstream (people will actually surf/email on their mobile devices while sitting in front of a desktop/laptop) so designing/achitecting with that in mind is really the only way to fly. I'm going to pint you to a couple of current articles on A List Apart which say it better than I can: Uncle Sam Wants You (to Optimize Your Content for Mobile) and Your Content, Now Mobile.

Nobody said this would be easy...

 

[learning_brain]

Thanks for the feedback as always essellar.

If you check out my own design site at wishingwebs.co.uk, you'll see that I can do responsive designs - which are relatively straight forward provided you don't mind re-designing your site 3 times!

To be honest, the problem with the site I'm referring to is that there is a lot of script for the fullscreen versions. For instance, the menu alone has a large number of images (for on hover effects) + banner script + outdated browser detection + RSS feed reader.

By using the user-agent, I was aiming to completely remove excessive code that isn't required on a mobile version.... thus improving load time.

I must admit, using css media types would have been more straight forward!

Interestingly, you mention changing the architecture for mobiles - but how is that possible with css media selectors? Surely you can only show or hide elements?

Richard

 

[learning_brain]

Uncle Sam Wants You (to Optimize Your Content for Mobile) and Your Content, Now Mobile.

Good articles by the way - thanks

 

[essellar]

I'll admit that it's just moving the problem from the back end to the style sheet, and not removing it altogether. You can do silly stuff like using ::before and ::after pseudo-elements to intercept and handle floats, change the display: settings, and so on. A lot depends on CSS3 selectors, pseudo-selectors and pseudo-elements, and it's a bit painful to restructure your brain enough for it to make sense (even a learning brain), since the CSS can conditionally inject content(ish stuff) in this brave new world. And there's stuff like background-size, the viewport units (vw and vh) and document root ems (rem) that can be the basis of all kinds of effects and display formats all given the same set of virtual building blocks. (Setting a background-image to, say, 2rem high and 1rem wide rather than, say, its 32px high by 16px wide intrinsic size, with left top and repeat-x as its position and repeat will scale with your layout if you choose an intermediate size between chunky big-screen resolution and retina.) Add to that the fact that I like to use base64-encoded data URIs for my smaller (<1KB) background images to reduce HTTP requests, and you can imagine that the style sheets get pretty big and complex.

The idea is to leave the HTML as unstructured (in the display sense, not in the information architecture sense) as possible (which, I gather, you are mostly doing already) so that the CSS can hoist and lower elements as needed to fit the display/device. It isn't perfect (since support varies), and it isn't easy, but it is the proverbial Way of the Future—mostly because the user_agent string is becoming useless and will probably get more useless over time. The alternative is JS, but that has its own hellish corner in the mobile space.