Loading JS

[Deadweight]

I currently have something that appends to the head of a file (well js and css).

Ironically, it works when i upload it to my server:
http://thebcelements.com/dhtml_test/load_js/index.htm
However, offline it doesn't work. Meaning the JS doesn't load. I'll post the loading script in here:

$(function(){
	appendToHead({
		css: ['css/main.css'],
		js: ['js/navbar.js','js/timebar.js']
	})
})

function appendToHead(a){
	var css = a.css;
	var js = a.js;
	
	for(var items in css)
		$('head').append('<link href="'+css[items]+'" rel="stylesheet" />');
	
	for(var objects in js)
		$('head').append('<script src="'+js[objects]+'"></script>');
}

[molendijk]

It works offline on my machine. There are 2 identical horizontal menus, though. After I hit HOME, that problem corrects itself.

[Deadweight]

Shouldn't be two menus. I think something was auto included when you saved it. I was stupid because i forgot to http://localhost/websites/Websites/cgs/index.htm
Lmao. It works also. My bad

[jscheuer1]

Escape the slash in </script>:

		$('head').append('<script src="'+js[objects]+'"><\/script>');

If you don't, the script interpreter may conclude that the script is ending there. Once uploaded, the code might be automatically escaped, or encoded in such a way as to not make that conclusion. If it's an external file, it probably doesn't need to be escaped. If it's on the page, it certainly should be.

BTW, you are iterating over arrays as if they're objects. You can, but it's inefficient. With only one or two members, it doesn't matter so much. It can also lead to assigned prototypical properties being included in the iteration when this might not be intended. Using the numerically based:

for(var i = 0; i < arrayName.length; ++i)

syntax is generally preferred. Using a numerically based while loop is even more efficient. Either will ignore prototypically assigned properties and only iterate over numerically indexed elements.

[Deadweight]

Alright, thanks. I will keep that in mind. For me it was just shorter code and i was wanting to test to see if it it would append the css/js to the head. I switched it an added the slashes.

Also, for my navbar.js is this the best way to detect the path select file (eg index/about/contact us/etc..):

var pathname = window.location.pathname;//gets path name
	var finalPath = pathname.split("/")//splits it to an array
	var firstLink = $('#nav_left>li:eq(0)>a').attr('href');//gets the first a tag in nav bar
	
	//checks to make sure the path isnt blank. If blank set it to the first link else get the final 
	if(finalPath[finalPath.length-1]=='')
		pathname=firstLink;
	else
		pathname=finalPath[finalPath.length-1];
	//end if
	
	$('#nav_right, #nav_left').children('li').addClass('not'); //sets all values in the nav bar to .not
	$('#nav_main a[href="'+pathname+'"]').parent().addClass('selectedPage').removeClass('not'); //clears not style and sets it to a selected style!

[jscheuer1]

I'm not really sure I follow. I generally see what it's doing, but without several different example first links and the subsequent changes (if any) that brings to see what the results would be in different situations, I cannot be sure. If it works, as long as that's not a coincidence, I guess it's OK. In general, I would advise against using javascript to set paths. Depending upon the situation, either the absolute, network, or relative path, used in ordinary HTML, should be sufficient.

[Deadweight]

Here is an example of what i mean
http://cgs.thebcelements.com/index.htm

[jscheuer1]

OK, now I think I get exactly what you're talking about. Seems fine to me on the use you have put window.location.pathname. The one thing that jumps out at me, and I believe I've noticed this in other code of yours that I've seen but never mentioned it before, is the use of a negative class name (not in this case). Why have a .not class when the resting (not selected) style of the links can just as easily be those with no class or without the selectedPage class. That's how it's generally done. One selector (made up of the elements themselves, like #nav_main li) controls all of the nav links, and the added selector (#nav_main li.selectedPage in this case) adds to that to create the highlight and/or whatever added/changed styles. There's no need for a not selected selector, and therefore it never needs to be assigned or removed. Makes the javascript more efficient.

[Deadweight]

The reason why i use .not is for this .not:hover
If i had #nav_main li:hover it would fail to work. Look at my navbar.js and see how it is made.

[jscheuer1]

I think you could still have #nav_main li:hover and a later #nav_main li.selectedPage:hover that would either negate or use a different hover style (in your case, simply restate the non-hover property/value pairs of the .selectedPage item, but open to change if the user of your code desired). Again, the object is to simplify the javascript and return control of style primarily to the stylesheet.

Put another way:

#nav_main li {
	/* basic nav styles here */
}
#nav_main li:hover {
	/* basic nav hover styles here */
}
#nav_main li.selectedPage #nav_main li.selectedPage:hover {
	/* how the selected nav should look regardless of whether it's being hovered or not */
}

That said, one of the reasons I never mentioned it before was because it is a finer point.