Modern browsers routinely fix invalid html by rearranging elements in the DOM, but when you create the same html-structure with JavaScript, it remains intact. Why? This seems consistent across browsers. Is there a W3C recommendation how such cases should be handled? Under what circumstances can we expect browsers to intervene?
For examples, see the following JSFiddle: https://jsfiddle.net/od0uwxsb/
It includes span-Elements in place of td-Elements and table-Elements inside p-nodes. In both cases browsers fix the invalid html in the initial load, but keep it intact when the structure is created dynamically.
Related
I have a page, generated by a server that has bad LI elements, with two closing li tags
<li>Whatever</li></li>
All jQuery operations work fine in Firefox, but not in IE (7 and 8). I want to remove the duplicate </li> before I start my functions, how do I do it?
Not possible to fix via the client, unless you have a browser that defies logical sense. jQuery controls the DOM, not the raw HTML, and as a result, it can't edit the scrubbed broken tag. Just fix your server-side script.
If you really want a hacky, terrible, awful JS solution, you can AJAX request the page itself after that page is loaded, remove the AJAX call from the page (to avoid an infinite loop), remove the broken elements and then load that HTML in a new window. PLEASE never do that.
If possible you should of course fix the code that generates the page.
If that's not possible, you have a rough road ahead. You can't fix the markup, because it's parsed before you can do anything about it, so you have to fix whatever the browser generated from the broken markup.
Each browser will have a different way of handling the incorrect code, so you have to test every possible browser that you can get your hands on, including every current version of Internet Explorer (7, 8, 9, 10 and possibly 6). That is a pain in the ass, as you can only have one version of IE installed at a time. Luckily you can use the developer tools in newer versions to simulate older versions, however it's still not a 100% accurate emulation.
Some browsers may ignore the extra ending tags, and some amy add extra list elements. You have to write code that handles whatever each browser generated from the markup, and fix the elements.
I've seen several threads about reading contents, but nothing on writing to noscript.
$('body').append('<noscript><div></div></noscript>');
In Chrome and IE9 I get a noscript-element with a empty div inside like I expect, but in IE7 and IE8 I just get a empty noscript-element without the div inside.
Example: http://jsfiddle.net/cEMNS/
Is there a way to add HTML inside the noscript-tag that works in all browsers? What I need is to add some tracking code into a noscript-element at the end of the page, but the info I need isn't available until after document ready.
Edit: I'm getting a lot of comments on "why". It's some poorly done tracking library that requires this. We don't have access to the code to change it. Regardless, I find it interesting that it works in some browsers and not in others since jQuery was supposed to work equally in all browsers. Is it simply a bug?
Edit2: (2 years later) Adding a noscript on the browser doesn't make sense, I know. My only excuse not the question the task I had was because of lack of sleep, like everyone else in the project. But my rationale was that jQuery should behave the same on all browsers and someone might want to do this on the server.
Regardless of the tracking code, what you are doing (or are required to do) makes no sense!
Why? There are two cases possible here:
user has JavaScript enabled in which case the NOSCRIPT get's inserted into the DOM but is ignored by the browser (does nothing)
user does not have JavaScript enabled, NOSCRIPT does not get inserted and does not "execute"
The end result of both cases is that nothing actually happens.
Just an idea: You could try giving your noscript tag an ID, and then try to use native js.
for example:
$('body').append('<noscript id="myTestNoScript"></noscript>');
document.getElementById('myTestNoScript').innerHTML = '<div></div>';
I would claim that if it does not work with native js, it will not work with any library (feel free to correct me on this one).
I tried following simple HTML code:
<html>
<body>
<noscript>I'm a noscript tag.</noscript>
</body>
</html>
Then I did analyse this with IE8 (in IE7 mode) and his integrated code insprector. Apparently the IE7 checks are script allowed. If so he declared it as empty. And empty tags will be ignored. Unfortunatly I could not try that with disabled script option, because only the Systemadministrator can change the settings (here at my work).
What I can assure you, the noscript does exists. If you add
alert($('noscript').size());
after the creation, the result will be 1.
The following piece of code, works correctly in Firefox and Chrome, but it gives me a headache in IE.
var anotherDiv= document.getElementById("anotherDiv");
var destination = document.getElementById("mySourceDiv");
destination.appendChild(anotherDiv);
I'm trying to get a Div element and place it inside another div.
I get an error message (in the debug console in IE) similar to "interface not supported", and points me to the appendChild line.
What I've seen is that the type of the destination variable is an object rather then a DOM element.
What can I do to append the anotherDiv to mySourceDiv?
I'm trying this in IE 8.
You probably will need something like an importNode, there are various cross browser solutions around. The issue is that each node has a corresponding document object on it, in IE and so called security doesn't play nice moving things from one document to another.
So, essentially it's doing a deep clone, but the difference between using cloneNode is that cloneNode also sets the document which you don't want.
This might get you going in the right direction:
IE support for DOM importNode
I'd recommend using a library designed to sort through the browser incompatibilities for you. I've personally found jQuery to be quite good. jQuery has an append function.
Can I somehow load a "broken" DOM tree in JavaScript
for example if someone forget to close a tag..
The current page? ...if this is an HTML document (ie. not served as XHTML) then the browser will auto-close (and even attempt to 'fix') certain elements that may at first appear 'broken'. When reading the current DOM, you are reading the fixed version. However, if the page is in fact 'broken' (or is just not standards compliant) then different browsers will 'fix' it differently. Depending on how broken is "broken", this may or may not be OK. If you are wanting this to work cross-browser, then this is probably not OK.
I am testing the speed of different methods to dynamically add html elements to the DOM. I've build a tester here (code is working version, so pretty sloppy). The results are (very) different for different browsers with Chrome getting all the points for speed, and Opera a good second - but that's not the question here.
In Firefox I detected a problem with clearing a div (from it's childNodes). When some 50.000 div elements are added, it takes ages to clear, using just
[div].innerHTML = "";
What is going on here? Did firefox implement some intrinsic garbage collection method for this?
While I am not sure about the innerHTML = "" you left out one possibly fast appoach using DocumentFragments for inserting into the DOM: As John Resig shows.
As Ólafur Waage already mentioned, even though innerHTML is faster in a lot of situations since it's not part of any W3C standard, quirks are far more likely to be introduced then if they were. Not to say innerHTML is not a defacto standard within modern browsers.
This blog post seems to indicate that Firefox spends a lot of time cleaning up after itself when using innerHTML to remove elements.
In some browsers (most notably, Firefox), although innerHTML is generally much faster than DOM methods, it spends a disproportionate amount of time clearing out existing elements vs. creating new ones. Knowing this, we can combine the speed of destroying elements by removing their parent using the standard DOM methods with creating new elements using innerHTML.
innerHTML is not a part of the W3C DOM specification.
It should never be used to write parts of a table—W3C DOM methods should be used for that—though it can be used to write an entire table or the contents of a cell.
As there is no public specification for this property, implementations differ widely. For example, when text is entered into a text input, IE will change the value attribute of the input's innerHTML property but Gecko browsers do not.
For those wishing to adhere to standards, here is one set of JavaScript functions offering to serialize or parse XML so as to set element contents defined as string(s) via the DOM or getting element contents obtained from the DOM as a string.
Source - Mozilla Dev