Printing jQuery manipulated pages

Filed under: css,jquery,web development — jaydublu @ 5:26 pm

I’m working on a page which is using jQuery to show one block of content at a time from a group of blocks, managed by a navigation. It’s working very nicely, but geting to the later stages I start trying to get print styling working.

Ordinarily, I’d attach a print stylesheet and hide irrelavant things like navigation, and show anything that I want to print that is hidden as per Eric Meyer’s classic article in A List Apart ‘Going to Print‘ – in this case it would be ideal to have all the content blocks printed. But jQuery has rewritten all styling so the print stylesheet which loaded with the initial page rendering can’t help. Or can it?

After much research, herad scratching and good old ‘suck it and see’ experimentation, I’ve determined that yes the theory still holds, you just have to apply a bit more brute force.

jQuery manipulates page styling through use of inline styles. Linked stylesheets can still override inline styles if given a ‘!important’ suffix. So for instance: <style media=”print”>.switchable {display: block !important;}</style> should keep content hidden by $(“.switchable”).hide(); visible.


Filed under: jquery,opinion,web development — jaydublu @ 4:03 pm

Every now and then I come across a new product or technique that causes a lightbulb to come on – suddenly I know I will never code the same way again.

Landmark events over the years might include the realisation that PHP is a proper programming language (although I did keep Perl up my sleeves for the odd task), how to use Subversion to version control a website (must write that one up sometime), reading Zeldman’s “designing with web standards”

Not quite in the same league perhaps, but I’ve finally got around to having a good play with jQuery, and doesn’t that open up whole new fields of possibility?

Having ‘bought into’ Standards there has always been an internal conflict with any superfluous markup that has to go on a page for eye candy or other frippery, such as the dreaded rounded corners problem. Suddenly, there is a simple way to tinker with the DOM to make such effects possible, without having to put anything more in the base code than a few calls to JavaScript includes. But it sounds too good to be true. It can’t be legal can it?

I suppose the answer to that is that there isn’t one answer – it all depends how you wield the tool. If you disable JavaScript and the page still ‘works’ – then all jQuery is doing is adding some glitz and if it’s keeping the markup etc. cleaner and more semantic then that has to be a good thing.

But what is the definition of ‘works’? It depends what the page is meant to do. It could be an informative page so ‘works’ is can you access the content in the correct context and get appropriate meaning from it. Or it might be a bit of functionality – a form or a blog or whatever.

With the power comes responsibility, and the temptation to run riot and get all inappropriate. I’ve seen some pretty dubious examples of the use of jQuery – putting ‘back to top’ links on a page, or altering anchors if they link to external resources – that starts risking Accessibility and potentially usability. Use of AJAX without a non-js method of doing the same thing – form validation and submission for instance. Face it you could use it to construct a whole site on the fly if you wanted. But that would be a Bad Thing in my book unless there was exceptional reasoning behind it and some sort of mitigation for non JavaScript users.

I’m sure I will be making a lot of use of jQuery in the future, but I will be keeping a close check on myself to make sure it’s appropriate. For reference, here’s a simplistic view of how I tend to approach a new build currently:

  • Analyse what the page is about and prioritise requested / identified features in a sort of MoSCoW list
  • Design html structure to represent it, check it makes sense in text browser
  • Analyse ‘look and feel’ requirements and design css / JavaScript to implement them
  • If necessary adjust html to make the presentation layer easier / possible, but as little as possible (argue negotiate with client / designers as appropriate)
  • Never forget a print stylesheet, and probably nowadays it would be good to consider mobile devices
  • Do everything server-side to deliver the page and handle any actions the page produces
  • Complete content population & coding
  • Test degradation from latest browsers with everything turned on through old browsers, text browsers, phones, anything I can get my hands on until I get bored- ensuring ‘must have’ features work in all, ‘should have’ and ‘could have’ work in as many as is feasible.