A project I'm currently working currently has about 10 ULs, each which will have anywhere from 10-50 elements in them. Its been proposed that each of those elements have a unique ID specified to it that we will use to update content with via Javascript.
This seems like a large number of IDs to add to a page, but each field will have a real and meaningful name.
If this is useful to us, are will adding IDs to this many already existing elements have any effects on performance while initially rendering the page or traversing/modifying it with javascript?
In my personal experience I've implemented pages with over 1000 unique IDs and even IE seem to cope quite well. However, please remember that IE will create a global variable for each ID on the page and remember that in javascript, commonly both global variables and function names are merely attributes of the window object.
So in IE the following code will break:
<div id="foo"></div>
<script>
function foo (txt) {
document.getElementById('foo').innerHTML = txt; // fail in IE
// because function 'foo'
// clash with ID 'foo'
}
</script>
Just something to keep in mind because with such a large number of ID's chances of function names clashing increases.
I took Eddie Parker's advice. Further, I was interested in the difference between short ID's (<10 characters) vs long ID's (>50 characters).
My test used FF2.0 to open a page with n DIV tags, each with an ID, containing only the text "Content":
5000 Short ID's: 1.022s to load from localhost and render
5000 Long ID's: 1.065s to load from localhost and render
50,000 Short ID's: 6.702s to load from localhost and render
50,000 Long ID's: 6.792s to load from localhost and render
Hope that gives you a ballpark.
Edit:
I was using the YSlow extension to perform the timing.
I can't answer authoritatively, but why don't you just write a script to generate yourself a ridiculously large ul list, and test rendering performance with/without id's? Then you can test it across a multitude of browsers while you're at it. Then post the answer up here and you can answer your own question and earn a shiny badge. ;)
It shouldn't take very long to implement a python script to output that.
Adding all the id attributes of course means that the page source gets longer, which might affect the load time somewhat. Other than that, the effect would be minimal. Just having the elements in the page clearly causes a lot more work than adding an id to them.
Related
The webpages of a certain website are all constructed out in sets of tables. Basically, each set of tables is constructed from scripts.
There are about 80 table tags in the DOM of any webpage I've checked in that site (I counted 77 tables in one page in the DOM). A very old site.
Some element children (td) include some tables inside themselves.
I Came to the conclusion that webpages in that site are constructed from scripts because of two reasons:
1) Either of these won't work on basically any table element in a webpage:
document.querySelector("#mySelector").style.display = "none";
document.querySelector(".mySelector").style.display = "none";
document.querySelector(" /* LONG-CSS-PATH-TAKEN-FROM-DEVTOOL (via "Copy CSS path") */ ").style.display = "none";
Such action will usually output:
TypeError: document.querySelector(...) is null
Ofcourse, all 3 examples work fine on other websites.
2) There are script segments before different parts of the DOM.
My question:
My question is comprised of the following two questions:
1) How could I prevent loading of a particular script that creates a certain set of tables? (a certain part of the whole webpage)?
I ask this because it seems to be the only way to hide some elements in this odd layout, given that targeting them traditionally (ID, Class, CSS-PATH) gives the above error.
2) May there be another reason than "loading HTML from scripts" that causes the elements not to be targeted in the traditional way?
Notes:
I run this script from Console.
I also tried to run it with Greasemonkey inside a window.onload event handler.
If you can see the element in the DOM, you can query it.
One possible explanation for the behavior you're seeing is that the elements are being loaded into the DOM after your query. You haven't provided enough clues to offer any practical advice other than to figure out what scripts are being loaded and take it from there.
Another possible explanation is that the tables are in iframes. Querying against the DOM of the top frame won't return elements in the DOMs of other frames. You might see them in the DevTools Elements pane because it shows all the DOMs, but you have to get a reference to the correct frame's document before your can query it.
Last but definitely not least is the very simple question... WAT? What's going on there? Hundreds of tables? It makes no sense, even by the standards of the late 90s when using tables for layout was considered a good idea.
Your strategy shouldn't be to hide them but rather to completely get rid of them. Consider running away.
I have been searching around for quite a while on ways to do this, and I'm beginning to think it's not doable. I can't say I'm an expert in html or CSS, but I have done a lot of research and found no tutorial for this specific problem.
I am coding a software user's guide to be posted online. The guide will include screenshots of the software, with figure numbers. The original code (I'm not the first on this project) simply hardcodes in the numbers of each image, which becomes more and more tedious as more information is added in.
I know there is a way to simply add in a new image and then tag the caption to include an automatically incrementing figure number. This would be very helpful, for if a new figure is added in, the numbers automatically change in all of the figures after the new one.
IF that were the only facet of the problem, I would simply use a CSS counter and be done with it. However, I also want to be able to reference specific figures in the text of the guide. My question is this: Is there a way to do this in CSS?
An example of text within the guide would be "Figure n shows the dialog box for customizing x." Is there a way to reference the nth figure in the guide without hardcoding the numbers?
If this is not possible in CSS, is there another language that can do it?
Edit: To clarify: The figures themselves would be labeled consecutively. But if I wanted to, within my text, refer to Figure 3, for example, that could be anywhere.
Edit 2: I have tried a javascript implementation using arrays. However, now it seems that some versions of Internet Explorer refuse to show the script portions of my code.
I am using the <script></script> tags within the body of my document, calling a javascript function located in the head. I know the syntax must be right because firefox and google chrome both load the page just fine. Is this simply IE being picky about something? (I checked, it's not my security settings).
Thing is, referring to things by their page index (incrementing) and by some figure number you maintain (also incrementing) are two identical solutions.
Actual problem: Maintaining the figure list with a sequence of ordered numeric identifiers becomes more difficult the longer a document becomes.
Solution: Give figures names, not numbers, and generate a number for display to the user. This gives ordered numbering to the user and allows you to reference figures with memorable names, but does not require you to reorder or modify figure numbers after every edit. Here's a quick example using jQuery:
<h2>How to add a contact</h2>
<img id="add-contact" class="figure" src="figures/add-contact.png" />
<p>This screenshot shows the location of the Add Contact button.</p>
<script type="text/javascript">
$(function() {
var figNum = 0;
$(".figure").each(function() {
figNum++;
$("a[href='#"+$(this).attr("id")+"']").append(" (figure "+figNum+")");
});
});
</script>
I need to find out if Google Chrome has a limit on Javascript execution that may slow down some scripts. I'm sorry in advance i cannot post any HTML or examples, but i will try to explain the problem as thorough as possible.
We have a page with a very complex structure (tables within divs within tables at least 20 levels deep) and there we have the core of the page split into 2 parts: on one side is a list of categories(1000 divs or so), and on the other are attributes that need to be mapped to them(10 or so). The 1000 categories each contain 10 tags within them( 4 span, 1 ul's and 5 divs) can also load their subcategories, increasing the number even more.
now, the main problem is that the attributes need to be dragged to the categories in order to execute the mapping, but then you start to drag, it sometimes takes more than 10 seconds for the dragged element to appear, and up to a minute when you drop it (the actual ajax executed in under half a second).
On Firefox the slowness is not such an issue (the script is still slow, but it executes 10 times faster). Is Chrome limiting the script execution resources? If so, can you give me any ideas on how to circumvent this from happening?
I wouldn't have thought Chrome would be limiting resources, it would be good if you tried the app on different operating systems with the stable, beta and dev versions of Chrome, just to see what the results are like across the board.
It's a shame you cannot post example code, a complex HTML structure linked with complex selectors might be the reason behind the slowness, is there no way you can show any HTML + JavaScript, perhaps with no private data in.
If not perhaps just try to simplify the markup and selectors, cannot think of much else, hands are tied without code.
Is there a difference between ...
this
<html>
...
<div id="myDiv"> </div>';
...
</html>
var manyHtmlCode = ' ... many Html Code ... ';
// onclick -> write it in to the DIV -> $('myDiv').append(manyHtmlCode);
and this
<html>
...
<div id="myDiv" style="display:none;"> ... many Html Code ... </div>';
...
</html>
// onclick -> show content $('myDiv').show();
It is obvious to me that the second solution is faster in javascript, but what about with the browser speed?
Is the browser faster (for example, draging a div) with a smaller HTML code in the body Tag?
If so, it would be better to store not needed HTML code in a JS var. My Problem is that i have a page with many many draggable divs. Imho is the dragspeed better when the html code is smaller.
The second solution is faster for two reasons:
The HTML in this approach is 'static' HTML; it exists in the response to the browser, and doesn't need to be parsed or interpreted by JavaScript to get added to the page.
When parsing and rendering the HTML, the browser will notice the display: none and not bother rendering that element nor anything inside it. This speeds up the initial render of the page, because it doesn't actually render a lot of your HTML.
I would use second one, because it is faster to execute. (1 call of jQuery instead of 2)
If you have too many DOM items then i would suggest go with first one.
Suppose you want to traverse DOM and look for an element , if you have less elements then traversing will take less time.
My suggestion is to benchmark your code. And use the one that suits best to you.
You can use below tool
http://jsperf.com/
Depends on what exactly you wanna achieve. Yes the second one would obviously be faster as the HTML is already present in the Document, which the jQuery unhides. While in the 1st method the jquery is writing the content in real time.
Again there may be different ways to achieve what you are trying, like you could write divs u have edited into a file using ajax etc etc .. and remove it from the current document. Thus reducing the amount of html in the document.
I'm just giving you an idea here.. the thing is u haven't clearly explained what you are trying to achieve to give you the most suitable solution
Is there a difference between ...
It depends on the meaning of "is".
On a particular version of a particular browser, one or the other will run faster. You can, if you wish, benchmark them on five or 10 different browser versions and find out which usually wins.
But so what? The user won't be able to tell the difference; the user's computer typically isn't doing anything else, so there's no point in conserving the CPU cycles.
My advice to all programmers -- but especially to programmers writing for browsers -- is to ignore time and space efficiency until you see a problem and focus on
Correctness -- the code performs as designed, even in the face of unexpected inputs, changes in the underlying platform, and similar challenges;
Maintainability -- the code is written so it can be altered as requirements change; and
Usability -- the code presents an interface (either the UI in the case of end-user code or API in the case of library code) that allows a user who lacks a complete appreciation of the code to still use it correctly.
Efficiency, bah.
Using element id's is the fastest way for javascript to 'get' an element. Is there a rule of thumb or best practices guideline on how many of these id's should be used before one can expect browser performance to start degrading?
An ID, in and of itself, is just an attribute value. The only 'performance' issue is extra bits and bytes the browser has to download. From a JavaScript POV, the more elements in the DOM, the longer it can take to traverse it, but that's not directly related to the number of IDs you may be using.
EDIT:
To clarify if your JS is this:
document.getElementById("myID")
it doesn't matter if your HTML looks like this:
<div id="div1">
<div id="div2">
...
<div id="div999">
<div id="myDiv">
or this:
<div>
<div>
...
<div>
<div id="myDiv">
The JS should run the same for both of those examples.
A complex page means more bytes to download and it also means slower DOM access in JavaScript. It makes a difference if you loop through 500 or 5000 DOM elements on the page when you want to add an event handler for example.
A high number of DOM elements can be a symptom that there's something that should be improved with the markup of the page without necessarily removing content. Are you using nested tables for layout purposes? Are you throwing in more s only to fix layout issues? Maybe there's a better and more semantically correct way to do your markup.
A great help with layouts are the YUI CSS utilities: grids.css can help you with the overall layout, fonts.css and reset.css can help you strip away the browser's defaults formatting. This is a chance to start fresh and think about your markup, for example use s only when it makes sense semantically, and not because it renders a new line.
The number of DOM elements is easy to test, just type in Firebug's console:
document.getElementsByTagName('*').length
We've got a form with over 1,000 fields (don't ask), using jQuery Validate for client-side validation. This includes validating which fields are required, checking the data type of each field, showing/hiding groups of fields based on certain criteria and running calculations across multiple fields as data is entered.
Only MSIE slows down at this scale. Firefox and Chrome run the validation "instantly". MSIE eventually shows the "long running script" dialog. I was notified last night that additional fields are now required.