How can I make the browser display changes at once?
in [JavaScript]
|
Prev: FAQ Topic - How can I disable the back button in a web browser? (2010-04-17)
Next: FAQ Topic - How do I access a frame's content? (2010-04-18)
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 10:32 VK wrote: > Thomas 'PointedEars' Lahn wrote: >> VK wrote: >> > While the situation is as it is: one crucial point to remember about >> > onload handlers - *a lot* of sites keep being affected by it. >> >> > window.onload / body onload= / addEventListener('load',.. >> > do not mean "display the page and start the script execution" >> >> > They mean KEEP THE SCREEN BLANK until the script executed, apply DOM >> > changes if any, and only then display the page for the first time. >> >> Nonsense. > > The test case is posted. I hope I can skip at least on step-by-step > instructions how to copy it, paste it into an editor, save as a > (X)HTML page and open in a browser. So much you should now. The test case is very far from being suited to the task, Often Wrong. To begin with, this short a document is insufficient to prove that your assumptions about the timing are correct. The problem with you is your flawed "reasoning" (for the lack of a better fitting and equally polite term): You have no data as you do not know and, by your own account, do not want to know what you are talking about (which includes, but is not limited to, the fact that you do not accept public specifications as the basis of implementations, even when their implementors confirm that they are). Then you are observing something unexpected, which to you must be pretty much everything that happens because you have no data. Then you set up, or rather size up, test cases for a specific scenario that work in favor of your changed expectations in the limited number of environments that you are capable of/willing to testing with, without checking the additional conditions that may have lead to the observed behavior, let alone checking your premises. Often, so here, you post those test cases without even mentioning the environments and additional conditions in which you think you have observed the newly expected behavior, so that any behavior you might have observed cannot be reasonably reproduced by others. The result of that dysfunctional thought process of yours are your knee-jerk generalizations this newsgroup has to witness (and endure) all over again. If Richard Cornford would be the Sherlock Holmes of this newsgroup, you would be Lestrade of Scotland Yard (apologies to Scotland Yard), trying to lock away the wrong person again and again. See my sig. PointedEars -- "I have no data yet. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts." -- Sherlock Holmes in Sir Arthur Conan Doyle's "A Scandal in Bohemia"
From: VK on 18 Apr 2010 10:44 On Apr 18, 6:32 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > The test case is very far from being suited to the task, Often Wrong. To > begin with, this short a document is insufficient to prove that your > assumptions about the timing are correct. .... etc... Learn Javascript, improve your practical programming skills, find topic more interesting than "JavaScript doesn't exist". If you need an opponent on "JavaScript vs. Javascript vs. javascript vs. ECMAScript" or "HTML5 - does it exist or not?" or "getElementById method is missing - how should we properly workaround this actual problem" - if that then don't knock my door for that. ;-)
From: Johannes Baagoe on 18 Apr 2010 10:45 Thomas 'PointedEars' Lahn : > So you would want a DOM implementation to trigger a reflow every time > you change a DOM property? > /* x refers to an object representing an element in the document */ > x.style.position = "absolute"; > x.style.left = "10px"; > x.style.top = "20px"; > x.style.width = "100px"; > x.style.height = "200px"; > x.style.color = "blue"; > > No, if you think about it a bit harder, Please do not presume how "hard" others think. Or, if you cannot help making such presumptions, don't air them publicly. > you will find that you really don't want that. I take it that you mean "Imagine what would happen if you apply many successive changes to an element, causing many recalculations of the page layout". (Like if `x.style.position = "absolute";` were the *last* instruction in your example rather than the first, and anybody would be crazy enough to actually do things like that.) My point is that one should never write it that way. Rather (assuming HTML or XHTML with default namespace): var new_x = x.cloneNode(true); new_x.style.position = "absolute"; new_x.style.left = "10px"; new_x.style.top = "20px"; new_x.style.width = "100px"; new_x.style.height = "200px"; new_x.style.color = "blue"; x.parentNode.replaceChild(new_x, x); That way, the "small" changes are accumulated into one "big" one before being submitted to the page the user sees, and the browser has to render. The browser (or its implementers) may assume that when the programmer says "Replace that child!", she means "Now!". For small examples like this, cloneNode(true) does the job. (Or even innerHTML, if your religion allows it.) There is no need for DocumentFragments. They are handy, however, when you receive per XMLHttpRequest a few kilobytes of responses from an XQuery database and have to whip them into something the user likes to see - an outline with several levels of detail, headings, tables, SVG piecharts, etc, properly cross-referenced with `a` elements and `href` attributes. Client-side XSLT is the obvious solution, and most implementations quite reasonably provide it in DocumentFragments rather than in some existing subelement of `document`. -- Johannes
From: Sean Kinsey on 18 Apr 2010 11:04 On Apr 18, 4:45 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: <snip> > My point is that one should never write it that way. Rather (assuming > HTML or XHTML with default namespace): > > var new_x = x.cloneNode(true); > > new_x.style.position = "absolute"; > new_x.style.left = "10px"; > new_x.style.top = "20px"; > new_x.style.width = "100px"; > new_x.style.height = "200px"; > new_x.style.color = "blue"; > > x.parentNode.replaceChild(new_x, x); Unfortunately, this wouldn't work well with attached event listeners now would it? > > That way, the "small" changes are accumulated into one "big" one > before being submitted to the page the user sees, and the browser > has to render. The browser (or its implementers) may assume that when > the programmer says "Replace that child!", she means "Now!". > > For small examples like this, cloneNode(true) does the job. (Or > even innerHTML, if your religion allows it.) There is no need for > DocumentFragments. And for big changes? Take for instance gmail, when you tick the 'check all' checkbox, would you have gmail clone and remove the entire parent container? For just setting a couple of setAttribute("checked","checked") calls? Or when hovering on elements not supporting the :hover pseudoselector, should the same thing happen then just to add/remove a single class? Do you see no problems with the aforementioned attached event listeners, memory usage and speed (due to having to clone and rebuild the entire node-tree)? > > They are handy, however, when you receive per XMLHttpRequest a > few kilobytes of responses from an XQuery database and have to > whip them into something the user likes to see - an outline with > several levels of detail, headings, tables, SVG piecharts, etc, > properly cross-referenced with `a` elements and `href` attributes. > Client-side XSLT is the obvious solution, and most implementations > quite reasonably provide it in DocumentFragments rather than in some > existing subelement of `document`. This is pretty much irrelevant.
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 11:54
VK wrote: > Thomas 'PointedEars' Lahn wrote: >> The test case is very far from being suited to the task, Often Wrong. To >> begin with, this short a document is insufficient to prove that your >> assumptions about the timing are correct. > > ... etc... > > Learn Javascript, improve your practical programming skills, find > topic more interesting than "JavaScript doesn't exist". > > If you need an opponent on "JavaScript vs. Javascript vs. javascript > vs. ECMAScript" or "HTML5 - does it exist or not?" or "getElementById > method is missing - how should we properly workaround this actual > problem" - if that then don't knock my door for that. ;-) <http://pointedears.de/scripts/test/dom/events/window-onload.mpeg> Will you *please* shut up now? PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.) |