i have a page with many divs on which i need to implement some JavaScript functions. Is there a way to tell the browser to sort all divs by for example id so that I can find quickly an element.I generally don't know how browsers handle searching of elements, is there some sorting or not on major browsers firefox, chrome, ie? How do elements get indexed?
Every browser already holds a such an index on id's and classes for use with, for example, css.
You shouldn't worry about indexing the DOM, it's been done and ready for use.
If you want to hang events on elements, just do so. Either by use of 'document.getElementById(id) or document.getElementsByClassName(class) (that last one might bump into IE-issues)
I think jquery will help you in that case...
or with simple javascript you can getElementById, or getElementsByTagName
the browsers creates a tree like structure named DOM (Document Object Model), with the root being the html tag for example, then it's children, their children's children, etc..
There are functions that let's you access the DOM and find the required elements. But this is done in the browser's inner implementation. You can not change how it handles the page elements, just use the browser's API to locate elements
Related
I'm looking at ways to improve performance of my single page web app, which will need to run on a variety of devices including lower-end phones.
I've got 8 modals (Twitter Bootstrap but this question applies to any framework) that add over 200 elements to my total page DOM element count (783). Is it worth having these as strings in Javascript rather than code in the HTML, and injecting them when needed into the DOM immediately before display, then removing them afterward? Would strip live DOM size down by a quarter, thus making e.g. JQuery element searches quicker, lighterweight page etc.
I was thinking to use JQuery's $.detach() and $.append() for example
Anytime you modify the DOM, you take a performance hit because the browser will have to "reflow" and "repaint" the UI. As such, keeping those modifications to a minimum will help, however doing modifications in batches absorbs some of that performance hit (i.e. changing 3 DOM elements separately is more expensive than changing all 3 at once). So, group together your DOM changes as best you can.
The actual mechanism you use to inject the new content could either be by:
Passing a string of HTML to the HTML parser and asking it to parse
on demand the string. This is essentially the same as the process
that happens when the page is being parsed from the server. Using
the standard .innerHTML or JQuery .html() accomplishes this.
You could also build up the DOM element in memory first and then
inject that node into the DOM at the right time (i.e. document.createElement or document.createDocumentFragment). I generally favor
this approach as it is more programmatic, vastly reduces the
possibility of string concatenation and quotation errors and is
cleaner to read. From a performance standpoint, this gives you the
benefit of getting some of the work done prior to DOM injection
time. This would be the equivalent of the DOM .appendChild() or
the JQuery .append() methods.
In the end, today's modern user agents handle DOM changes much better than they used to and either approach is viable. It's the really bad techniques (like modifying the DOM in a loop) that you want to stay away from that, in the end, will make a difference.
Ok so I am wondering which way is the preffered way to access a certain tag.
Is it better to use..
document.getElementById('myDiv').innerHTML
or this way..
document.getElementsByTagName('div')[0].innerHTML
// I use [0] because it is the first div in the body
My guess is that it doesn't matter at all which way i do it.
Absolutely the getElementById is better in that case. It's much faster.
Update
Here is a test about JavaScript selector functions. http://jsperf.com/queryselectorall-vs-getelementbyid/6
There are not many articles about performance of JavaScript selector functions. Instead there are many articles about jQuery selector performance like this or this. jQuery uses native JavaScript selector functions internally, so you can guess from these articles.
They do completely different things. If you want to get a particular element and you always need to get the same element, use an id. If you want to get a particular element based on what place it has in the DOM, then use the it's position in the getElementsByTagName NodeList.
If you want to get a particular element and you get it by index, then your script will be brittle - if you change your DOM structure later, you will need to change your code. If you want to get an element by it's position, then using an ID will require you to add redundant attributes to your markup.
Also, it is important to note that getElementById returns a DOM node, while getElementsByTagName returns a NodeList. To quote MDC on the properties of a NodeList:
NodeList is live, meaning that it updates itself automatically to stay in sync with the DOM tree without having to call document.getElementsByTagName again.
So if you need a particular element, getElementById will be significantly faster.
For readability purposes, it depends on what you're trying to do.
Is your intent to get the first div, which just happens to be named myDiv? if yes, then I think getElementsByTagName is better, as it would more express what you're trying to do.
Or is your intent to get myDiv, which just happens to be the first div? If that's the case, then use getElementById.
All other considerations aside, go with the one that expresses your intent.
Is there a way to query an embedded flash element to determine the available methods that can be executed on it via JavaScript?
Edit:
It appears that in IE it's as simple as
for ( i in flashNode ) {
alert(i);
}
After much clicking, they will be some of the very last members enumerated.
Still not able to determine this in Firefox though.
While it is possible to get the callbacks by enumerating the <object> DOM node in IE, they are mixed in with all the other properties of the DOM node and they are unable to be progamatically distinguished without keeping a list of known properties to compare them against and then taking the difference of the two sets.
This approach is questionable since properties can be arbitrarily added to any DOM node. Worse, it only works in IE. Firefox (and possibly others) does not return callbacks as a property of the <object> DOM node.
I believe it works the same way in FF and other browsers, but you may need to get the reference to your swf element differently than IE.
IE will use an object tag, generally with an id, and ff/safari/etc will use the embed tag, and since you aren't supposed to be the same id on two elements, people generally use the name attribute instead of an id attribute on the embed tag.
If you are using something like SWFObject to embed your swfs, then you should only get one or the other (object or embed) and whichever one gets written will have the id attribute set with whatever you specify, so then you could iterate over the object.
The basic scenario: I've got a series of elements on an HTML page, generated dynamically. (Currently, they're all divs, but they don't need to be.)
What I want is a javascript function that will loop though all of those divs (or whatever) looking for the presence of a specific value.
What's the best, most cross-browser way to do this? Does getElementsByName() work on divs in all browsers? Can I give them all the same ID and get an array back out of getElementById somehow?
If I change those divs to spans or inputs, does that make things easier?
Thanks!
(edit: it would be best, for this project, if there was a solution without using any external js libraries. I assume jQuery has a function that does just this in one line, but for the moment I'd like to avoid opening that can of worms with the client.)
getElementsByTagName is defined in DOM Core, so any browser which implements that works. That's about every browser in current use.
Take a gander over here for the specifics: http://www.quirksmode.org/dom/w3c_core.html
One gotcha to be ware of, is that getElementsByTagName returns a NodeList - not an array. It works the same, but it is evaluated very late, so if you add/remove nodes to the DOM while traversing a NodeList, you will get weird results. In these cases, write two loops; First loop through the NodeList and store all entries in an array - Then loop through the array.
It doesn't matter what the elements are, but what does matter is where they are in the page. If they are all child elements of a single parent element, your problem is simple. Give the parent element an ID and you can use getElementById() to grab it and iterate its children.
getElementById() behavior is undefined when more than one instance of an ID is found in the document. Most will return the first Element they can find, but you certainly can't cound on getting an array.
getElementsByTagName() will work only if you can use some obscure tag that you are sure won't appear elsewhere in your page. You could augment this by specifying that the elements you are interested in will have an attribute present that you can check for (such as #class or #title). You can then loop through the result of getElementsByTagName() checking for this and only look at Elements where the attribute is present.
You can use this site to see what getElementBy most suites your needs.
There are some using libraries and some like troelskn wrote that apply for standard javascript in all supporting browsers.
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 ?-)