Jon,

Did you refresh the page each time after disabling/enabling?

Changing style sheet is overrated. Keep it consistent!

Excellent tutorial! Thanks very much. I will be implementing this soon.

Great way done… A more comprehensive way could have been reach here, or maybe easiest. Nevertheless it’s usefull and AJAX seems to have great way to prevent us from poorness and sillyness. Just say Whhoo? :-)

Is there a working demo up anywhere?

That was nice of you to include the link to the Beta but do you have any websites utilizing this we can all check it out?

Guys – read the article! It links to an example page

Nice, thanks Dustin. Glad 24Ways is back online too :)

Thanks for the positive feedback so far guys.

And ditto what ^{Drew said}

There is a link in the article itself to the example :)

Thanks a ton for havin’ me too Drew ;) You rock!

PC IE 6.0 – worked with javascript, disabled javascript and worked again, re-enabled javascript and it does not work.

Hi Dustin

Maybe this is a stupid question, but if it works without javascript why not leave the javascript out altogether? (OK I know that means it’s not AJAX anymore)

This may be an obvious one, but if you include the stylesheet switcher throughout your site, it would be best to make the non-javascript links point to the active page. Instead of linking to index.php use $_SERVER[‘PHP_SELF’]

@Andy,

That would entirely defeat the purpose of this. As we all know, The JavaScript version would be more robust and occur ‘on the fly’ not to mention that PHP style switchers have long been around for quite some time.

@Justin,

Yep. That would be most ideal and a smart thing to do. I’ll just leave it up to the developer to figure that out and implement it how they like. But yea, that’s definitely the right track.

Dustin, I don’t think Andy likes AJAX.

Oh..sorry, I must’ve missed the link the first time. See it now…

I’ve got nothing against AJAX at all. I was just confused about how the style-switching worked and how you did the switching without the Javascript. Opened the demo page in Firefox with javascript off and it all became clearer.

@Andy: Glad you understood :)

@Viktor: It is not in fact over-rated as it has proved itself useful for many reasons such as font-resizing, zoom-styling, and page-printing. I’m sure others can throw out many other great reasons as well.

Great article Dustin! I might find a use for this.

Nice short tutorial. I is an excellent idea. Great stuff!

Superb! Thanks for sharing!! Ive been using the ALA switcher for a while and found it to be really good but your method just rocks. It seems to be pretty robust and degrades so well. Im working on a new design at the moment and it took me 10 – 20 mins to implement this switcher.

@Viktor: Yes, keeping a design / style consistent is really important for many reasons, but a style switcher isn’t just about switching style, colour or graphics, its a tool to help the user customise the website to their needs (wide, thin, high-contrast, text only), whilst allowing the designer/developer to maintain control over the layout, what is shown etc.

Thanks Dustin!

@Paul: Lemme know where you decide to implement it. I’d eventually like to come check it out :)

@Heiko: Thanks man. I had this idea for weeks – I just finally got around to writing it :)

@Dave: This article was inspired by Paul’s ALA Style Switcher – So hopefully you’ll still be receiving the same benefits but more :)

Cool idea and nice work, but how is this really AJAX when the page does a complete reload for each switch?

Seems nice. Only thing I’ve noticed is that if a person’s user agent allows them to change to alternative styles manually then the cookie is not updated. To fix this you would need to figure out the what user agents categorize such an event (something I’ve never seen documented) and add an event handler for this event that would create an Ajax request that merely updates the cookie OR just set the cookie client side.

I’ve been using this method by Noscope. Have to try this version also…

@Coward: Read the article – coward ;)

@Brian: Interesting idea. I suppose the idea here is that the only people doing that would be the one’s purposely trying to mess it up. You should see to it that you’re making it clear to your users that you’re giving them the ability to update their style preferences via your own methods.

Otherwise, you’d probably have to figure out a way to set cookies based on if certain images getting load from the alternate styles…

@Vesa: that version is a PHP only version.

@Dustin: You’re right, it is clear that that is what you’re attempting to do, I just see it as some users may actually use features in their browsers, and it isn’t our fault that they would like to do so. Sure there are some features we shouldn’t code for (for example, we shouldn’t assume that they are using Firefox and have an extension that will do something), but those are rare cases. As it stands, this is probably one of the niftiest style sheet switcher I’ve seen, so I love it.

That said, I am by no means an expert JavaScripter as I’ve only been toying around with it for a short time, but to me it looks like you are cancelling the click event before you test whether or not the browser has Ajax ability. Does this not run on any browser that can’t support Prototype (I haven’t looked into Prototype to thorougly yet), and it’s just chance that all browsers that are supported by Prototype must have Ajax?

Shouldn’t we be developing for users without JavaScript, then for users with JavaScript but not Ajax, and then Ajax versions? This hits the non-JavaScript users and the Ajax people, but does nothing for people with JavaScript but not Ajax. If the click event was not cancelled, then non-Ajax JavaScript enabled users would fall back to non-JavaScript version. Is that too sharp a fall to degrade them that much? Should it then fall into another branch of code that makes it similar to your average client side style sheet switcher? If that branch is present, isn’t Ajax overkill? This question holds true for every Ajax application. Is this one of those times?

I don’t really have an answer for that (and since it’s 4:52 AM as I write this, I don’t know if that answer would even make sense), but I think it gives us something to ponder.

Brian,

That is by far probably a very small minority group of a people, thus tackling something very big with a lot more cost. But as Joe Clark would say, “access by nature is for the minority – and yes, it does cost money”

The only thing that comes to mind if you really want to have this degrade for folks with JavaScript enabled but no xmlHttpRequest support (or the ActiveX comparable) – do a quick object detection first before canceling the click event. There, problem solved :)

Otherwise, Prototype did the rest of the Ajax Development cross-browserness for us! It truly is quite the time saver.

Nice article, but two well-grieved issues are not discussed.

A. Please don’t ask for the link where stackoverflow.com even links the tools to hack and redirect “unprotected” PHP style switchers (I’m knowingly expecting they’ll be bugging me for awhile). Is your PHP, um… protected?

B. It may just be a niggle to some, but lots of Google links to complaints that PHP switchers are not switching graphics styled as backgrounds and so on.

Does your java script manage basic security (so CSS collector isn’t a loose handle)? And does your java script haul out all those picture images (likewise with secure handles?