Discuss: Invasion of the Body Switchers

by Andy Clarke, James Edwards

21 Doesn't work in Konqueror 3.3.1

There is no stylesheet switching widget in Konqueror 3.3.1 over here too.

posted at 02:02 am on November 20, 2004 by Jonathan Tan

I like the trickery of what is shown in this article, although I personally like to opt for a server side solution since that gives a little less trouble with browser-side compatibility issues; if of course you have a server side solution at your disposal (like PHP or ASP). I take the trips to the server for granted.

The thing that has been bothering me with all style selection methods that are not supported by the browser is when you offer a stylesheet that is targeted at a specific audience (the high contrast example); if someone cannot distinguish the selection boxes on the original page and needs the high contrast to see anything at all, how will that person be able to switch?

I guess that the “alternative” stylesheet method that browsers like Firefox or Opera support are the preferred way for someone who needs a particular stylesheet in the first place, so should we use AND a body switcher type selection AND offer the ‘alternative stylsheets’ in the head of the document at the same time?
(I realise this is beyond the scope of the article, but nonetheless)

posted at 03:14 am on November 20, 2004 by Martijn

23 Thanks

Thanks for giving great opportunity, more contror to document. Amazing!

posted at 03:31 am on November 20, 2004 by John

24 I am not so sure

>> this doesn’t trouble me, because … many browsers do not implement native style-sheet switching

But wouldn’t this take away the expected behavior of the browsers that do implement switching? The multiple stylesheets would not be switchable by the browser’s built-in switcher, and the user will have to use the controls on the webpage.

Also, the fact that browsers don’t support different media is only a temporary problem that will eventually be fixed as the need arises – at least we have the semantics in place. By using this method as a quick-fix, won’t we be repeating the old-style web design mistakes of generating dirty code that breaks semantics and doesn’t really work as intended in every browser?

Or am I missing something entirely?

posted at 06:13 am on November 20, 2004 by Rakesh Pai

25 Well ...

The reason for the traditional switcher not supporting multiple media types is that the semantics don’t have scope for it – we don’t have the semantics in place, and that’s why it was necessary to go outside them – abandon them, in fact – in order to acheive multi-media capability.

Open to suggestions though :) Just because we couldn’t think of another way, doesn’t mean there isn’t one.

> if someone cannot distinguish
> the selection boxes on the
> original page and needs the high
> contrast to see anything at all,
> how will that person be able to switch?

That’s an interesting point … maybe that implies that a separate, basic switching mechanism tied to the original semantics is still useful.

> As for the script not functioning
> in IE/Mac, I found two possible
> reasons for this. One is that the
> onload event handlers don’t work
> in IE/Mac. The other is the space
> before the class name which seems
> to throw IE/Mac off.

We used those event handlers specifically so that mac/ie5 wouldn’t attempt to run the script. If that’s changed, it still doesn’t work, because dynamically creating and populating a select element is fundamentally broken in mac/ie5 – it just creates a bunch of text nodes outside an empty selector. As far as I know there’s no way to fix that, so mac/ie5 is degraded to unsupported.

> instead of the more verbose …
> I’d opt for just …

But scripts run faster if there are no strict-compilation errors – the shorter example would throw a strict warning :)

> This circular reference cannot be
> cleaned by IE/Win … the problem
> can be solved by not keeping references
> to DOM nodes on the object and retrieving
> needed nodes using a getElementById call.

Yeah I’m aware of this issue, but it’s a browser bug, and when it comes to changing your code to suit browser bugs .. well we all draw the line somewhere, and I draw it well before the point where I’ll re-structure my code so fundamentally.

Personal choice, obviously. If the memory leak is a serious concern, this code tacked on the end of the script will clean it up:

//add DOM cleaning function for win/ie
if(typeof window.attachEvent != ‘undefined’)
{ window.attachEvent(‘onunload’, function() { //for each item in the document.all collection this.daLen = document.all.length; for(var i=0; i<this.daLen; i++) { //set its onchange property to null //so that if this object is one of our selectors //the property can be garbage collected document.all[i][‘onchange’] = null; } });
}

posted at 09:41 am on November 20, 2004 by James Edwards

26 Just What I Need

This is just what I need for the project I’m working on at the moment. Worth the wait!

posted at 09:45 am on November 20, 2004 by Tony Bittan

27 Ooooh!

Well written article, if I must say so myself… A more robust method of delivering alternative styles. Brava!

-Shade

posted at 04:03 pm on November 20, 2004 by Shade

28 nice!

welcome back to the mix ALA!

Nice article, at the present I use PHP switchers but will have to take another look at this as well….

posted at 04:15 pm on November 20, 2004 by clint

29 Nice method, more interface options needed

James, Andy: thanks for this great article and method. My only complaint is the interface. Many who use this method will only want to include the screen styles switcher on their site. Of the sites I can think of that use screen style switchers, nearly all of them use buttons, not dropdowns. How about some more interface options for those who don’t want ugly dropdowns on their site?

posted at 05:32 pm on November 20, 2004 by Joshua Kaufman