Is document.InnerText a variable?
If not then why it has assignment operator like this code below:
document.InnerText=count
I tried to reverse the count and document part it doesnt work the other way.
Look at this diagram of the HTML Document Object Model. You'll see document is the top of the tree. It contains a root element, which is the html, which contains every html element in your web page.
Only the html elements can have innerText. Here is a list of the built-in methods and properties of the document object; innerText isn't in there. But JavaScript objects are built on the fly (unlike in most object oriented languages like Java, where they must be defined in advance). Try saying document.potato = 7. The JavaScript interpreter will happily create a potato property within the document and assign the value 7 to it.
What does this do to the web page? Nothing at all, because the potato property means nothing to the engine in the browser that draws the page. But if later on in the program you say console.log(document.potato) it will print 7 in the console for you.
So when you say document.InnerText=count it will create the property. But like potato it doesn't do anything, because the browser engine doesn't recognize that property. That's why it's not doing anything.
Related
I have a web page with the element:
<div id='myid'></div>
In chrome dev tools, when I type in the console
document.getElementById('myid')
returns a html element,
<div id='myid'></div>
is there an alternative method I can use to view it and it's properties as a JavaScript object instead rather than a html element?
convert html to javascript
I have seen this post, but all I want to do is get the element, not do any parsing and build something new and ideally in dev tools.
is there an alternative method I can use to view it and it's properties as a JavaScript object instead rather than a html element?
all I want to do is get the element, not do any parsing and build something new and ideally in dev tools
Yes if you are only interested in the dev tools (console), you can always use console.dir() method, it's made for this:
console.dir(document.getElementById('myid'));
console.dir() method:
Displays an interactive list of the properties of the specified JavaScript object. The output is presented as a hierarchical listing with disclosure triangles that let you see the contents of child objects.
Would do something like using the Document Element interface to access the array of attributes / properties.
In Chrome, when debugging in JavaScript, it is interesting to get the interface of an element.
Typing the variable name that holds the element in the console usually gives me the element tag. How can I get the interface matching the element. Sometimes Chrome outputs it, but sometimes gives the tag. I am unsure how Chrome returns the value.
Browsers try to be smart when displaying things via console.log to make the output more readable. If you want to consistently get a tree of properties that you can navigate through, you can use console.dir.
interface has no meaning in JS and a very specific meaning in other languages. You can potentially see the WebIDL interface of a DOM Element by viewing the prototype of an element using console.log(element.__proto__); but that is entirely browser dependent and non-standard.
If you want a standard way (i.e. not using __proto__):
console.log(el.constructor.name);
It looks like you can force one view or the other by specifying which you want:
console.dir(el)
gives you the "interface" for that el, while
console.dirxml(el)
prints the element as it would appear in the Elements panel.
Similar to how 'Pause on exceptions' works, is it possible to pause whenever you create a svg element and sets invalid attributes on it?
This example (test on jsfiddle):
circle.setAttribute('fill', 'steelblue');
circle.setAttribute('r', 'big'); // A 'big' circle is obviously wrong
will generate the following error in chrome, but there is no mapping back to the javascript call that generated the svg so it can be hard to find the error:
This is not possible because of how svg is rendered in the browser. Imagine that svg is a like XML, or (HTML) for that matter. Its not executed in a step process like lines of code. Its read into a rendering engine that quickly renders the object and its attributes. The pause would have to happen during this rendering, inside of the engine, and this would cause all sorts of rendering issues.
In reference to your example, javascript doesn't do any sort of type checking on what you pass into the setAttribute value, (I mean it really couldn't as different attributes require different types), but rather adds that key value pair to the element object. (try logging the circle object, before and after and you'll see what I mean). Later when you add your circle to the DOM, it simply takes the object and parses it like I stated above.
Basically this type of error handling will never exist in the browser because the code that you have in your example is correct and executes properly, however you as a programmer need to make sure that you are passing the correct type of value to the setAttribute method. So its not an error in the javascript and that is why you do not get the breakpoint there.
You could create a wrapper which does type-checking. Read the SVG spec to determine what values are allowed for each element's attributes.
I have two divs for different sections of my webpage, a working and a reference section. One is fixed size, the other is variable sized and they are vertically stacked. I am trying to design it so that if you want to work on something in the reference pane, you click a link and it swaps all the data between the two panes. My idea was to do the following:
var working = $("#working_pane").html();
var ref = $("#reference_pane").html();
$("#working_pane").html(ref);
$("#reference_pane").html(working);
The problem with this, is it seems that any javascript referenced inside of these panes (for example, in place editors) get broken upon switching. No javascript errors occur, it's just that nothing happens, like the javascript ties are broken.
Is there any to move the html without breaking the javascript contained?
When you are working with bits of an HTML document, you should aim to work with the Node objects that are the content as the browser sees it, not HTML strings.
To get HTML the browser has to look at the Nodes and serialise them to a string. Then when you assign that HTML to another part of the document (with innerHTML or jQuery html(...)), you are telling the browser to destroy all the content that was previously in the element, laboriously parse the HTML string back into a new set of Node objects, and insert these new Nodes into the element.
This is slow, wasteful, and loses any aspect of the original Node objects that can't be expressed in serialised HTML, such as:
event handler functions/listeners (which is why your editors are breaking)
variable references other JavaScript code has to the Nodes (also breaks scripts)
form field values (except, partially, in IE due to a bug)
custom properties
So — and this applies whether you're using jQuery or the plain DOM — don't throw HTML around! Take the original node objects and insert them into the place you want them (they'll leave the place they originally were automatically). The references stay intact so scripts will keep working.
// contents() gives you a list of element and text node children
var working = $("#working_pane").contents();
var ref = $("#reference_pane").contents();
// append can be given a list of nodes to append instead of HTML text
$("#working_pane").append(ref);
$("#reference_pane").append(working);
This could be happening maybe as a result of duplicate ids. basically you may have element a in a div which has the id=id1 now this gets stored in a var and gets injected into a new div. now currently seems you have no mechanism for making sure you do not have duplicate ids at the same time. this can break js
So look into this and if you do make sure elements are first stored in a var then the originals are removed and then appended into a new location.
I'm building the HTML code within an XML DOM object to be used as the contents of the innerHTML of a div element using an XSL template. Traditionally we create a new XML DOM document and add the input parameters as XML Elements for the transform via javascript. This is all very time-consuming as we are basically hand picking the data from another XML document that represents our current account and copying the data into a transient XML DOM document.
What I'd like to do is clone the relevant node of the account document (i.e. customer info) and use it as the basis for the transform. I don't want to use the account document directly as I'd like to be able to add transform specific input, without making changes to the account object.
How efficient is using .cloneNode(true) for a desired node of about typically less than 200 elements from a document of typically 2000+ elements? The target platform is IE6 with no external tools (i.e. ActiveX).
CloneNode is pretty efficient but it will be consuming more memory doing it that way.
Another approach to consider is to use a Template object and a processor, pass your additional/changed data as parameters to the processor and the element that you would have otherwise cloned as the input element. This approach would require fairly significant mods the XSL though.
IE will fail on certain things.
e.g. checked radio/checkboxes will not be checked when you add your copy to the DOM.
Example:
http://webbugtrack.blogspot.com/2008/03/bug-199-cant-clone-form-element-in-ie.html
http://webbugtrack.blogspot.com/2007/08/bug-242-setattribute-doesnt-always-work.html
To see what IE will actually return, try replacing the url with this in the Address Bar of one of your pages, and press enter.
javascript:'<xmp>'+window.document.body.outerHTML+'</xmp>';
If you are happy with the results, great!, but I think you'll end up less than satisfied at what IE returns (both in the DOM, and this "string" value equivelant.
If you don't need form-elements, cloneNode is a real reliable tool ...
-- and in inserting ajax-data it is incredible in efficiency ...
However, as especially IE has a history of having problems with name-attributes, it is inconvenient to address any of these if you insert data ...
-- I don't really understand your XSL(T)-using, to me it sounds like using a gas-station as a (not !-) convenient place to change a 1960 WV to a 2008 Skoda ...
Userely they have some common technology, though it is not used in the same way, computerization in some way is just a minor problem, the major problems is in nearly any other way !o]
Have you got any need for form-elements ?-)