Dynamically inserting JavaScript and CSS with JavaScript
Benjam,on the topic of  JavaScript
03.25.2009   |   0comment

Before we start this discussion, I’d like to point out that while dynamically inserting JavaScript and CSS can easily be done with PHP, or your server-side scripting language of choice, those solutions don’t apply to static HTML pages (what? static pages? what are those?), and I came across a situation where I needed a non-PHP solution.

On my personal website, I have a single static page, my home page. This page does nothing but provide links to the rest of my site, and as such, it does not need to be PHP driven with all the bells and whistles that go with it. Just some clean code, and some clean CSS to make it pretty. Recently I found a small JavaScript snippet that I wanted on my home page, so I added it, and it looked good. The trouble is that it’s a seasonal script, and it makes no sense to leave it on all year. So instead of editing my page twice a year to add and remove this script, I figured I could go one better and dynamically add the script to my page via JavaScript. After a quick search I found Dynamically Loading External JavaScript Files which has a couple of methods listed to do this. After looking them over, I decided the DHTML method would suit my needs better.

Here is that method:

function load_script(url) {
   var e = document.createElement("script");
   e.src = url;
   e.type = "text/javascript";
   document.getElementsByTagName("head")[0].appendChild(e);
}

continue reading “Dynamically inserting JavaScript and CSS with JavaScript”

Leave a comment ( 0 )


cssWithVars: jQuery plugin review
Benjam,on the topic of  jQuery
03.23.2009   |   5comment

A colleague of mine (Tim) introduced me to a jQuery plugin that I had not heard of before. The plugin is called cssWithVars. This plugin makes use of some JavaScript and jQuery magic to bring variables and reuse to the CSS world. I recently looked through the example given with the download, played around with it, took a look at the backend magic, and here is what I thought about it.

While the background magic is actually pretty simple (look for any properties using a variable, which are wrapped in [ ], and if found, look for the related selector, and insert the properties defined in that selector into the variable instance), the implications are great. What this means is that you can create various pieces of style that can be reused anywhere and when it comes time to edit those styles, you simply edit the one instance and they all work. Here is an example style sheet:

text_box { /* this becomes a variable */
	width: 100px;
	height: 100px;
}

notice { /* this becomes a variable */
	color: #F00;
	font-weight: bold;
}

p {
	[text_box] /* a variable in use */
}

h2 {
	[notice] /* another variable in use */
}

h3 {
	[h2] /* normal selectors can be variables as well */
	font-size: smaller;
}

p.alert {
	[text_box]
	[notice]
	/* normal properties can be used as well */
	border: 2px solid #000;
}

As you can surmise, changing the details of the [notice] variable (or any of the other variables) would be extremely easy. Simply change the color, or font-weight, in the selector where it gets defined and it propagates through to all the other instances. This, to me, is what got me intrigued by this plugin. It has far reaching implications, and can be a very powerful thing. But as with all great power comes great responsibility (and confusion.) With this, it becomes increasingly difficult to say what properties are applied to what selector, or even where they come from. Say for instance I have a variable that sets a border style and I use it in a property that also sets a border style, which one gets used? I would imagine the one that is set explicitly in that selector gets used, but then what if I am using two variable styles that both try to apply conflicting styles, one floated left, and the other floated right… what then? Which one is the intended style?

This could get ugly.

One more thing that you may or may not have thought of… What if JavaScript is turned off?

This little question is a deal breaker for me on this plugin. Not only is it a deal breaker, but it completely turns the tables on my recommendation of this plugin. Not only is the CSS completely invalid, but in the (not so) rare case that the user has JavaScript turned off, they are going to see, in the best case scenario, a completely unstyled page, and in the worst case scenario, a page that looks like it was rendered with IE (yes, that’s bad.)

It is for this reason that I recommend that, while this plugin has it’s intriguing ideas, and is certainly fun to play with, should not be used in a production environment, because it has a poor execution (through no fault of the developer, but due to the possibility of broken pages due to invalid CSS and disabled JavaScript.) But CSS spec writers take notice, this would be a great and powerful addition to CSS. But it would take a lot of thought to get some of the caveats I’ve mentioned here (and more that I didn’t) working together as the designer intended.

Leave a comment ( 5 )

Newer Entries »