81 :|

Thats the “custom insertion script” (per project) :)
(Different locations for different markup = custom script for the project to determine location, or which div, where needs to be appended).

Currently, the implementation is IN the source file. The implementation also depends on the markup. Hence, the JS source depends on the markup.

The implementation should be seperated from your source (different file), so that either can be modified in isolation.

posted at 07:32 pm on December 3, 2004 by Ned

82 CSS only solutions preferred

Nice article … but I still do prefer CSS-only (no-JS) solutions, since I can’t see any reason for not including alternate styles in the HTML markup.

RE: Firefox…
The @media=print style can be seen, if you change the choice in the drop down and then choose File Print Preview.

Nice to have ALA back :-)

posted at 07:50 am on December 4, 2004 by Fritz

83 Hmm ...

@Ned – no, the implementation does not depend on the markup. The JS has a single variable (an argument passed to the object) by which you specify where to put the switcher control. If you want that value determined by the result of another process, that’s up to you, but the script itself is fine.

@Fritz – because there’s no way to select those alternate styles for more than one media indendently.

posted at 04:47 pm on December 4, 2004 by James Edwards

84 Let me clarify ..

Sorry, because my last comment reads a little pissy.

What I mean is that, although the script does have a dependence to the structure of the markup – it wants there to be an element with a named ID, or not, with no in between judgement – that’s as good as a generic script can ever be.

If you want to modify it for your needs to make structural judgements, that’s cool, but it’s way beyond the scope of the core script – it would take a ridiculous amount of code, almost a whole meta-language, just to describe how it makes these judgements, and it would still get it wrong most of the time.

As I’m sure you appreciate, writing scripts for other people to use is completely different from writing something for your own site. You can second-guess yourself, but I can’t second guess everybody.

Ultimately, there has to be a point of distillation – a place where you tell the script what to do for a certain decision it can’t make itself. There’s no way around that … and this is (one reason) why elements can have ID attributes at all.

posted at 04:55 pm on December 4, 2004 by James Edwards

85 Anyway ... they can be separated

The “new bodySwitcher” directives that create the controls don’t have to be in the same script – you can put them somewhere else if you want.

posted at 04:59 pm on December 4, 2004 by James Edwards

86 many thanks

great article. after the first style switcher article, i used the same approach to implement color palette switching for a number of my projects. with a single click, the sites’ entire color scheme can change from half-a-dozen options. many thanks, ala. you help us not-so-creative people become more creative.

posted at 01:25 pm on December 6, 2004 by jared

87 True Ned, but...

I’m with you, Ned, I am. But I feel like you’re blinded by something here, not sure what… ;) But considering your comments:

“What happens if you have 4500 pages in an intranet, perhaps using 100 or so templates.
What happens if I need to add another div?

What happens if I want to update my script on 2 projects that both have 4500 pages, and a few hundered templates?”

That sounds like a job solved by some smart template architecture, and a global include. :) Yes, that of course doesn’t account for the situation where you spend two years salvaging a monster, but nothing is going to be easy in that situation! You’re fixing what makes slick implementations like this bothersome.

Besides, somebody made a point about how you’d determine where to create these in the absence of the <div>s… yes, you could do it programmatically, but then I think it goes beyond the scope of many ALA readers and developers in today’s world(myself included) which means it makes implementation more hunt-and-peck than plug-and-play. :)

But believe me, I’m with you. I’m also learning to better realize how to make compromises for the greater good, and I think this is an example of that.

posted at 06:36 pm on December 13, 2004 by Seth Thomas Rasmussen

88 thank you Malarkey

Thanks for the clarification Malarkey… I haven’t tried using non-screen media types yet and so hadn’t experiend the limitations of the previous switcher.

I look forward to a future revision which recaptures the LINK tags :)

posted at 03:04 pm on December 16, 2004 by Jon