Setting a Drupal 6.x COOKIE value for CSS / jQuery menu resizing...

[Wolf_22]

I'm working on a Drupal 6.x project and I'm trying to use jQuery to set a COOKIE value I can use throughout the user's visit to resize a menu based on his / her resolution (window.width and window.height).

I have the resizing functionality working--I've setup the sizing to work when the user resizes the monitor as well as when they refresh / load the page, but every time a new load or refresh happens, the resizing resets itself (it's using animation properties). So visually, it works but not like I'd like.

I need a cookie with the resolution values that I can tie this script into to maintain a constant sizing. Do any of you know how to do this?

[Wolf_22]

Okay, so this is what I came up with and I would love to get some feedback on this to make this a little more efficient because I'm sure there's room for improvement:

//Accomodate for window resizing...
    var timer = null;
    
    //Does the cookie already have anything?
    if($.cookie('font_size').length){
        var font_size = $.cookie('font_size');
    }else{
        var font_size = '';
    }

    //Accomodate for refresh resizing...
    $(window).load(function() {
        if($.cookie('res_width').length || $.cookie('res_height').length){
            var w = $.cookie('res_width');
            var h = $.cookie('res_height');
        }else{
            var w = $(window).width;
            var h = $(window).height;
        }

        if($.cookie('font_size').length){
            font_size = $.cookie('font_size');
        }else{
            if(w > 1280){font_size = '100%';$.cookie('font_size',font_size);}
            if(w < 1280 && w > 1024){font_size = '90%';$.cookie('font_size',font_size);}
            if(w < 1024){font_size = '80%';$.cookie('font_size',font_size);}
        }

        $("#nav ul.links li a").css('font-size', font_size);

        return;
    });

    $(window).resize(function() {
        var w = $(window).width();
        var h = $(window).height();

        $.cookie('font_size', null);
        $.cookie('res_width', null);
        $.cookie('res_height', null);
        $.cookie('res_width', w);
        $.cookie('res_height', h);

        if(timer != null) clearTimeout(timer);
        timer = setTimeout(function(){
            if(w > 1280){font_size = '100%';$.cookie('font_size',font_size);$("#nav ul.links li a").animate({fontSize : font_size}, 300);}
            if(w < 1280 && w > 1024){font_size = '90%';$.cookie('font_size',font_size);$("#nav ul.links li a").animate({fontSize : font_size}, 300);}
            if(w < 1024){font_size = '80%';$.cookie('font_size',font_size);$("#nav ul.links li a").animate({fontSize : font_size}, 300);}
        return;
        }, 100);
    
        
    });

The links are the elements I'm resizing the font-size of and right now, I *think* it's basically working but it's just kinda glitchy and I think it has something to do with the setTimeout, but I'm not sure.

Again, I'm just trying to resize a menu along with the resizing of the browser window but I'm trying to set a cookie as per the last resolution / font-size captured so that when the page reloads / refreshes, those last values are captured and used during the page load...

(It's a mess, I know, but it's just where I am right now. So any help here to make it better is very appreciated.)

[awasson]

I think what you're trying to do is create a responsive theme or at least the navigation for a responsive theme... You can do this entirely in CSS3 which will of course only work in CSS3 or you can use jQuery to check the viewport size and have the menu react as you have been.

I wouldn't recommend using cookies as they just get messy for something like this and if you have someone resizing their screen you run the risk of just writing cookie after cookie to their browser's cookie collection. I would just check the page size and react. The code will be smaller and simpler which I always find preferable. I often write this sort of stuff into a PHP block using drupal_add_js(); and have it show on all pages. Then I ut in some simple code using jQuery to detect page size and then I would set up some constraints to resize the menu or expand it depending on if it's < 350px or > 500 px or something like that.

[Wolf_22]

I think what you're trying to do is create a responsive theme...

Is that what this is called? I wish I would've known that... Might've saved me some time with Google.

You can do this entirely in CSS3 which will of course only work in CSS3 or you can use jQuery to check the viewport size and have the menu react as you have been.

I'd like to shy away from solely CSS solutions if possible.

I wouldn't recommend using cookies as they just get messy for something like this and if you have someone resizing their screen you run the risk of just writing cookie after cookie to their browser's cookie collection.

If *messy* means garbage collection, all I'd have to do is just set the cookie to null where appropriate. That's not that messy unless you're referring / implying / eluding to something else...?

I would just check the page size and react. The code will be smaller and simpler which I always find preferable.

I'm the same way but the problem I kept having was that the menu would keep resetting its size after each page refresh, which is why I went with the cookie. I could've used some PHP to store certain resolution values in the $_SESSION array, but I didn't go that route because I didn't want to have to do a bunch of rigging between PHP and JavaScript / jQuery (I came close to changing my custom.js file into custom.php and having it print out JavaScript / jQuery just to pass whatever I stored in the $_SESSION array, but after screwing with it, I thought that making a simple cookie value would be the best situation all around, and so far, I think it has been.)

I often write this sort of stuff into a PHP block using drupal_add_js(); and have it show on all pages. Then I ut in some simple code using jQuery to detect page size and then I would set up some constraints to resize the menu or expand it depending on if it's < 350px or > 500 px or something like that.

I don't understand why you prefer this route. In a disaster recovery scenario, you're more likely to lose data from your database than some flat files and every time you do anything with a Drupal install, you have to add that into a block whereas the inclusion of 1 JavaScript file from within the *.info script array boils it down to a matter of using a file in your theme. I mean, I guess it doesn't matter in the end as long as you get whatever it is you're trying to achieve. I just see it like this: you make 1 alteration in that *.info file to add a custom JavaScript file. From that point, on, you have a basic setup or development template to use. Your way, however, you always end up using a database-stored block that you have to configure AND place code in.

Again, it's all about whatever works, I guess. But I did what I did with the cookie because it works, so I guess we're one in the same man.

Thanks for the suggestions though. I'll admit that I never thought about adding a block solely for JavaScript. That's an interesting approach and one I'll have to mull over.

Do you know is that block code is executed before the page is rendered?

[awasson]

Yup, we're pretty much on the same page and I see why you want to do the cookie route as opposed to doing it without. Garbage collection was the only concern I had but as you say, as long as you null the cookies, it's all good.

Regarding JS blocks, I really like going that route because it's so much faster to edit the code from a block window and then executing it as opposed to having some included script that you edit and upload. It's all the same in the end but I just find it easier that way. I backup my DB's twice (two different backups) just in case and have a week of hard copies of my Drupal databases on hand just in case. That said, I've got some 40+ Drupal sites in the wild and even when MySQL or Apache has crashed the data wasn't damaged to the point where we needed to replace the data. "Touch Wood", it will remain that way too.

Also on the responsive front, check this our (second video) http://drupal.org/project/spark

Cheers,
Andrew

PS: I'll pull up some of my jQuery and post it regarding screen size, etc...

[Wolf_22]

Also on the responsive front, check this our (second video) http://drupal.org/project/spark

The concept they're bringing about in that second video is truly impressive, but I fear it might be a bite they can't stomach. The reason I'm pessimistic about their workings is due to that man's last bit of words in the video concerning, "...we're hoping to get some help with this, especially the coding."

I think their idea really is groundbreaking, especially in terms of content management and manipulation, etc., but the kind of competency of technologies and concepts involved is somewhat intimidating (for me, at least--ha). I mean, just think about it: it could be argued that no platform exists that does what they're trying to set out and accomplish. I suppose many have come close, but at what price? I'm willing to bet that albeit Wordpress, Joomla, Drupal, or any other; the only time a CMS has come close to that level of content management versatility is with either cumbersome markup generated by amateur modularity or else through hacking the hell out of a bunch of template files whereby the final product is likely no longer OSS where the prior probably no longer validates well.

But I hope they succeed. I really do! Having that thing that guy demoed in his vid. would be something I'd possibly pay money for. Truly ingenious... But also truly absent of any code, too.

(I wonder what he was using in his video?)

[awasson]

Oh they have the code working but it's just proof of concept stuff so they need to round all the jagged edges and clean it up. I'm editing a book at the moment about HTML5/CSS3 and it's actually really easy to accomplish all of this stuff in CSS3. It's just getting it to be backwards compatible that's the trouble. I love/hate CSS3 because it shows all these great UI approaches we can use but none of it works in CSS2 and less and most of it doesn't work in IE9 or less. HTML5 is the same way. Really cool but what about the majority of web browsers that don't support it.

The downside of everything they're doing with Project Spark (IMO) is that it depends on Panels and Panelizer which I don't know very well and am a bit leery of because of some of the messes I've seen Panels create. That said, it's pretty cool concepts they're talking about and the GUI for editing that's going to be the toughest work. I think it will be quite doable to set up code that has lower, mid and upper limits that determine the way it renders the regions and like you said, that's something worth pursuing.