i see that that template has some code to see if the client has the required version, and it does stuff if it has or it doesn't
and there is a <object> tag inside <noscript>
question: if the stuff is gonna work with the <object> tag anyway why would you need all that stuff above with the control of version if it has or not ?
What is inside the noscript tag is only run in the case that the user has turned off javascript in their browser. This is required for the Flex page to still work in that case.
The other code is inside of a script tag, and handles the creation of the flash object smoother than the brute force method in the object tag. It would prefer to use this method, but in the case that scripting is disabled, it will use the object method instead in an effort to still give the user what they want on the page.
That is why it seems that it appears twice in the page. For any given browser only one section should actually run.
Related
I'm trying to load a remote script with some function and the execute it inline in IE9.
However I encountered an error message that my function was undefined.
What it boils down to is that IE9 (and lower, it seems) executes the script in opposite the order I would expect. I made a simplified example, which still yields the same bug for me.
<script type="text/javascript" src="multibanner_rev04_tmp.js"></script>
<script type="text/javascript">alert('nr.2');</script>
The script has a longer path I edited out for readability, it only has an alert in it and nothing else.
the alert 'nr.2' executes before the one in multibanner_rev04_tmp.js in IE9
I've tried this on multiple computers with IE9, to make sure it wasn't the same problem as this: IE9 js load order and JQuery
Problem seems to be consistent. Also tried this on IE10, which does execute the alerts in the expected order.
I don't really get what's going on here, any ideas?
From your comment on the question:
The script is injected onto my page using yet antother script (through an ad-server), so that might be a problem worth checking out.
That's a completely different thing from what you actually have in your question. What you have in your question shows script tags in the markup; injecting a script with JavaScript is completely different.
There are two ways the ad script could be adding the script to the page:
Using document.write during the main page parsing to write out a script tag. You've said your page is XHTML strict. Using document.write to output markup to the page during the main parsing is invalid in XHTML, full stop. You cannot do it. If it works at all, the behavior is unspecified and you shouldn't rely on it.
If you want to use document.write during the main page parse, you have to stop using XHTML. At that point, the scripts will be evaluated in the order the parser sees them (regardless of how they got put in the parser's input stream, from the markup or via document.write).
By creating a script element (document.createElement('script')) and then appending that to the DOM. When you do this, the script is evaluated as soon as it's available. There is no order. It's just like using the async attribute in the markup (except that it's much more cross-browser reliable).
If that's how the script is added, you cannot rely on the order. If you control the script being added in this way, you could have that script check for whatever the other script provides and use setTimeout to defer its execution until that other thing shows up. If you don't, you'll have to delay the addition of the script element until you're ready for it.
(My first ever post to stackoverflow...)
Stating the obvious...the first script tag requires the browser to load a separate script file
whereas the second script tag has the javascript inline (in the HTML).
Assuming that you have "alert('nr.1');" at the top of your multibanner_rev04_tmp.js then it appears as though IE9 is executing the inline code first even though it
appears later in the HTML, which is incorrect behaviour according to this:
http://www.w3.org/TR/html5/scripting-1.html#script
If neither attribute [async or defer] is present, then the script is
fetched and executed immediately, before the user agent continues
parsing the page.
However, using IE10 with "IE9 standards" document mode set (I don't have IE9), I can't reproduce the behaviour you are seeing, which would sort of point towards a bug in IE9 itself or a specific version of IE9? I wonder what happens if you add a defer="defer" attribute to your second script tag ? (Just for diagnosis, because it's not strictly legal according to the standard without a "src" attribute.)
I've been searching for a while now, but I can't figure out how to load an entire page via AJAX and still execute all javascript and css.
Mostly I just end up with the plain text without any CSS.
Is there a way to do this? I tried jQuery.get, jQuery.load and jQuery.ajax, but none really work like that.
I have a different solution. You may try it with an iframe. Use jQuery to append an iframe script including all relevant codes into some part of your page (like some div). This may do it for you including CSS, like;
$('<iframe src="your_page.html"/>').appendTo('#your_div');
Or you may try something like;
$('<iframe src="your_page.html"/>').load(function(){
alert('the iframe is done loading');
}).appendTo('#your_div');
I have solved similar problem as following.
Download the webpage over ajax
Iterate it over and find any <script> and </script> tags
Get content from within these tags as text
Create new <script> element and insert there the code
Append the tag to your webpage
Another thing is you will need to somehow call the script..
I have done it this way:
I set standardized function names like initAddedScript callback which I am calling after appending the script to the page. Same as I have deinitScript called when I do not need the code (and its variables,..) anymore.
I must say this is awful solution, which likely means you have bad application architecture so as I have had:)
With css is it the same, but you do not need any handlers. Just append the style tag to your documents head.
If the page you load doesn't have any style data, then the external stylesheets must have relative paths that are not correct relative to the invoking document. Remember, this isn't an iFrame - you aren't framing an external document in your document, you're combining one document into another.
Another problem is that loading your complete page will also load the doctype, html, head, and body tags - which modern browsers will cope with most of the time, but the results are undefined because it's not valid HTML to jam one document into another wholesale. And this brings me to the third reason why it won't work: CSS links outside of the head section aren't valid, and the misplaced head section caused by your haphazard document-in-document collage.
What I'd do for compliance (and correct rendering) is this, which would be implemented in the Success callback:
Copy all link elements to a new jQuery element.
Copy the contents of all script in the head section
Copy the .html() contents from the loaded document's body tag
Append the link elements (copied out in step 1) to your host document's head
Create a new script tag with your copied script contents and stick it in the head too
Done!
Complicated? Kind of, I guess, but if you really want to load an entire page using AJAX it's your only option. It's also going to cause problems with the page's JavaScript no matter what you do, particularly code that's supposed to run during the initial load. There's nothing you can do about this. If it's a problem, you need to either rewrite the source page to be more load-friendly or you could figure out how to make an iFrame suit your needs.
It's also worth considering whether it'd work to just load your external CSS in the host document in the first place.
I suppose you are looking for something like this:
your page div --> load --> www.some-site.com
After a quik search the closest solution seems to be the one by "And": Load website into DIV
You have to run a web server and create a proxy.php page with this content:
Then your JQuery load() function should be like this:
$("#your_div_id").load("proxy.php?url=http://some-site.com");
NB. I have tested this solution and it should not load all the CSS from the target page, probably you'll have to recreate them. For example the image files stored on the remote server will not loaded, I suppose due to authentication policy.
You will be also able to view only the target page without the possibility to browse the target site.
Anyway I hope this could be a step forward to your solution.
Get your entire webpage as text using ajax
document.open();
document.write(this.responseText);
document.close();
OR
document.documentElement.outerHTML = this.responseText;
But you need to change the path of css and js pages in original webpage if the resulting webpage is in another directory.
I have a JavaScript variable that holds an image tag surrounded by an anchor tag. Pretty normal stuff.
myvar="<a href='foo'><img src='bar'></a>";
What happens in Firefox, is that even though I'm not choosing to document.write the contents of that myvar variable, I nevertheless see that the image referenced by the IMG tag does actually get loaded. You'd never know it's happening without having a HTTP proxy tool running. I see in Fiddler that image being loaded. I don't see the image in the page of course, because I didn't choose to document.write the tag into the page.
Is Firefox trying to be too clever and not-so-intelligently parsing through the HTML page, even through the embedded JavaScript in the page, and seeing an IMG tag and pre-loading it? It's the only explanation I have.
I'd have tried breaking up the img tag if I could recreate it in a simple test page, but I can't. If anyone here tells me yes Firefox 4+ definitely does that, then I'll change it to something like
myvar="<"+"a href='foo'><i"+"mg src='bar'></"+"a>";.
It'll be sad to have to do that (or one of the many other alternatives) but it'll work.
Is the JavaScript loaded from an external .js file or inlined in a script tag ? If inlined, you should make sure that it is not parsed as HTML content, instead declaring it as CDATA:
<script type="text/javascript">//<![CDATA[
// JS Stuff
//]]></script>
I see that Javascript code is normally in heading part of HTML code.
<head>
<script type="text/javascript" language="javascript" src="core.js"></script>
...
</head>
Is it OK to put the Javascript code in a body part of HTML code? I tested it, but it seems to work.
<body>
<script type="text/javascript" language="javascript" src="core.js"></script>
...
</body>
If so, why the examples of Javascript books put the javascript code in heading part?
If not, what's the difference between putting the javascript code in body/heading part?
Not only is it OK, it's actually better, since it lets the content come first.
If your viewers have a slow (eg, mobile) connection, it's better to send the actual content first, so that they can read it while the browser downloads the Javascript.
All the people saying it is better only applies if you are talking about at the bottom of the page (and that is an up for debate thing) from a code quality point of view, it is NOT ok to sprinkle script tags through your html. All references to javascript should be in a single place on the page, either the head (where they should be), or the very bottom (as a perf optimization)
Edit:
Basically, a web page is made up of 3 pieces; style (css), structure (html), and behavior (javascript). These pieces are all very distinct, so it makes sense to keep them as separate as possible. That way if you need to change some javascript, it is all in one place. If it is sprinkled through the file, it becomes much more difficult to find the code you are looking for, and that code basically becomes noise when you are just looking at structure.
It is the same arguments as why not sprinkle db access code all over your page. It has nothing to do with technical reasons, purely an architectural/design decision. Code that does different things should be kept separate for readability, maintainability, and by extension, refactorability (not sure if that last one is actually a word...)
You can do it, and people often do.
For example, people like to put their script tags just before the closing </body> to make web pages render quicker.
Also, if you do a script block after an element is created, you don't need to wait for DOM ready.
Be warned though, don't add, or remove an element from an unclosed ancestor in the markup tree (not including the script block's immediate parent element), or you will get the dreaded Operation Aborted error in IE.
Just something to add on:
I have preference of putting Javascript file right before </body>. My reasons being that:
Content can load and be shown first. If you load huge Javascript files first, which most are meaningless until the page is loaded, the user won't be able to see anything until the JS files are loaded.
Most Javascript code require to work with the UI can only run after the UI has been loaded. Placing the codes at the end of the html file reduces the need to use the onload event handler.
It is very bad habit to place Javascript snippets all over the HTML file. Placing all at the back of the HTML file allows you to manage your Javascript more efficiently.
It is legal according to the spec.
Most examples use them in the header as the headers come first and the browser will be able to parse the reference and download the JS files faster.
Additionally, these are links and are not part of the display, so traditionally, put in the header.
It is perfectly legal but there seem to be some differing opinions about it. Those who say to put all the javascript references in the head argue that the script is downloaded before the rest of the page become visible and dependent on it. So your user will not see an object on screen, attempt to interact with it and get an error because the javascript code is not yet loaded.
On the other hand, the argument goes that it takes longer to load all the script before the user sees the page and that can have a negative impact on perceived speed of your site.
JavaScripts inside body will be executed immediately while the page loads into the browser
Placing javascript at the end of the body will defer javascript load (ie: the page will render faster), but remember that any javascript function used for an event should be loaded before the event declaration, it is mainly because users may be able to fire an event before the page is completely loaded (so before the function is loaded)!
I used to put it in the head, then I've heard that it takes longer for the page to load so I started placing the scripts at the very bottom. However, I found out the most 'clean' way to do it is to place it in the head BUT you place the script inside a document.ready function. This way you have the best of both worlds. It is cleaner because it is in the head and it is not loaded before the content has been loaded, so there aren't any problems performance wise either.
With jQuery for instance, you can do it like this:
$(document).ready(function() {
alert('test');
});
The alert will only popup when the page has been fully loaded, even though the script is in the head.
I have partial control of a web page where by I can enter snippets of code at various places, but I cannot remove any preexisting code.
There is a script reference midway through the page
<script src="/unwanted.js" type="text/javascript"></script>
but I do not want the script to load. I cannot access the unwanted.js file. Is there anyway I can use javascript executing above this refernce to cause the unwanted.js file not to load?
Edit: To answer the comments asking what and why:
I'm setting up a Stack Exchange site and the WMD* js file loads halfway down the page. SE will allow you to insert HTML in various parts of the page - so you can have your custom header and footer etc. I want to override the standard WMD code with my own version of it.
I can get around the problem by just loading javascript after the original WMD script loads and replacing the functions with my own - but it would be nice not to have such a large chunk of JS load needlessly.
*WMD = the mark down editor used here at SO, and on the SE sites.
In short, you can't. Even if there is a hack, it would heavily depend on the way browsers parse the HTML and load the scripts and hence wouldn't be compatible with all browsers.
Please tell us exactly what you can and cannot do, and (preferably; this sounds fascinating) why.
If you can, try inserting <!-- before the script include and --> afterwards to comment it out.
Alternatively, look through the script file and see if there's any way that you could break it or nullify its effects. (this would depend entirely on the script itself; if you want more specific advice, please post more details, or preferably, the script itself.
Could you start an HTML comment above it and end below it in another block?
What does the contents of unwanted.js look like?
You can remove a script from the DOM after it is called by using something simple such as:
s = document.getElementById ("my_script");
s.parentNode.removeChild(s);
This will stop all functions of the script but will not take it out of user's cache. However like you wanted it can't be used.
Basically you can't unless you have access to the page content before you render it.
If you can manipulate the HTML before you send it off to the browser, you can write a regular expression that will match the desired piece of code, and remove it.