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: Johannes Baagoe on 17 Apr 2010 17:18 Thomas 'PointedEars' Lahn : > Johannes Baagoe : >> Thomas 'PointedEars' Lahn : >>> I can see no good reason for using XHTML there. I can also see >>> no good reason for serving *only* non-"HTML-compatible" XHTML 1.0 >>> Strict as application/xhtml+xml. Why would you want to exclude >>> e.g. the usually relevant IE/MSHTML from the tests? >> No good reason, plenty of bad ones. I am more used to work with XML >> than with SGML these days. I don't like when I can get away with >> forgetting to close an element with a close tag, or quotes around >> attribute values, etc. > Those are actually good reasons for using XHTML (although HTML 4.01 > Strict can alleviate the problem with the _end_ tags), I stand corrected :) > but not for serving it as application/xhtml+xml to user agents that > would support it with text/html instead. Perhaps. Nobody has complained so far, I may consider re-configuring Apache if somebody does. But I *hate* spending time on sysadmin tasks. >> I have tools on my editor that presume XML. > IMHO, this is not a good reason. I do not know which editor you are > using, but a good editor for Web development should be able to deal > with both HTML and X(HT)ML. Eclipse WTP/WST can. I usually simply use gedit, and occasionally emacs or vi if something requires it, e.g., very large files. And filters, standard or homemade, for command-line shell pipes. But my copy of gedit has an awful lot of homemade "external tools" that modify my documents the way I want. They very often assume that the document is at least well-formed XML. It essentially boils down to what I am the most comfortable with. >> I fairly often embed SVG in XHTML. > That is a good reason for using XHTML (although you can do without > the embedding and use HTML), but not for serving it like that. Isn't it? What happens, say, to XHTML form elements embedded in SVG embedded in the main document served as text/html? Or to click or mouse events in the SVG? I never thought about it, mind you, and I haven't tried. >> I use XSLT transforms. > That might be a good reason for using XHTML, and serving it as > application/xhtml+xml. I am not sure, but client-side XSL stylesheets > might not work with XHTML served as text/html. It should not matter > at all for server-side stylesheets. I use client-side, you may be interested in looking at the sources of http://baagoe.com/en/RandomMusings/javascript/index.xml Most of my pages are actually like that. (One example of the things I do with my filters and home-brewed extensions to gedit. The source is a text document with a simple indented outline format, the c and s elements are created automatically. I only use (X)HTML when I need something that my "slightly structured content" cannot provide.) > Or you could serve it as text/html to clients that do not support > application/xhtml+xml, based on the Accept-Type request header > they sent. That implies diving into Apache's configuration, and I hate it :) >> More trouble than I have cared to take till now. Is it worth it? > If you want the majority of Web clients to work with it ... (Currently > true regardless whether one of us likes that.) True, but my intended audience is not the average Microsoft consumer. > I do not use XHTML often (there rarely is a need), Whereas for me, XML is the "natural" thing, and it is making an exception like HTML that requires a definite need. > Regardless, once you serve XHTML as text/html to clients that do > not support application/xhtml+xml you will have plenty of evidence, > starting with the `script' element causing script runtime errors if > you write it like that. This newsgroup has seen it before. That would be an argument for *not* taking the trouble to discriminate, and serve everything as application/xml, wouldn't it? It keeps buggy browsers out, not to mention their users who are bound to pester me with questions about how to fix IE. Which I haven't the faintest clue about how to answer. >> The upper case is there to encourage users to think of it as >> returning that. No harm that I can see in pretending it is a >> constructor and calling it with new, if that is what one is used >> to do with Functions which return an Object of a particular kind. > You would want to deceive users and support their misconceptions > about proper use of the `new' operator? Ah, I think that would require a lengthy discussion. But not now :) > AIUI, the purpose of your question was to increase the responsiveness > of your application. In a single-threaded environment that boils > down to increasing the runtime efficiency of the underlying code. Ah, but that wasn't quite my point, at least, not gaining a few microseconds by looping backwards in a loop that gets executed all of five or six times. I rather wanted to know if there was a way to avoid setTimeout altogether - except when I need its intended functionality, that is, when I actually want something to be executed in the future after a given delay. -- Johannes
From: Johannes Baagoe on 17 Apr 2010 18:41 Jeremy J Starcher : > Johannes Baagoe : >> Sean Kinsey : >>> Javascript is singlethreaded, >> Of course, but it seems to me that my problem is unrelated to >> that fact. > The browser window is single threaded. Aha. The browser window, not only javascript, and they share the same thread. Now, *that* sure makes a difference. Ouch. > Opera, AFAIK, uses two threads per window. One to run the user > interface code and update the DOM and the other run scripting. > (I'm only guessing at details.) > So yes.. Opera does something that no other browser I know of does. > Everywhere else you have to let your script quit running and let the > browser breath (and repaint the screen) then continue your script > based on some event. OK, I get it. And even if there *must* be some other thread or even a full-fledged process to take care or communications, user events, etc in the background, it does not usually interrupt the javascript thread periodically in order to allow rendering to take place. Which I assumed, since "cooperative multitasking" (shudder) fell out of fashion with MacOS 7 - it was archaic even then. But it seems that now, we are back to having to call something "as often as possible", to quote then Inside Macintosh. (Re-shudder.) > If you don't believe that the fact that the browser window is single > threaded is the point, then change what you believe. Well, again, if the *browser window* is single threaded, I understand. -- Johannes
From: Thomas 'PointedEars' Lahn on 17 Apr 2010 20:33 Jeremy J Starcher wrote: > The browser window is single threaded. Where did you get that piece of "wisdom" from? PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Johannes Baagoe on 17 Apr 2010 22:46 Thomas 'PointedEars' Lahn : > Johannes Baagoe : >> If I want the whole result of a lengthy computation to be displayed >> once and for all at the end of that computation, I build the entire >> new tree as a DocumentFragment, and only append - insert - replace >> it when I am done. Or if I am lazy, I build the entire String to >> be inserted - /horresco referens/ - as innerHTML before actually >> inserting it. Contrariwise, when I update successive sub-nodes >> of `document.documentElement` *in situ*, it means that I want my >> changes to be displayed *piecemeal*, at the moment I insert them >> where they are supposed to reflect what the user sees. >> Something like `document.render()` when I mean "Now!", or perhaps >> `lazyRendering(false)` once and for all, would be welcome. In their >> absence, the net result appears to be that I must resort to an ugly >> hack to force what IMHO should be the default behaviour. > It is impossible for the DOM implementation to know what you are > up to, It doesn't have to, it just has to obey orders. DOM implementations are not qualified to question their human programmers' judgement. > so many implementors take the conservative approach and queue all > your DOM "requests" until there is sufficient time allocated to the > process to do so. That is a Good Thing! I find it most annoying - downright rude, actually. It assumes that I don't know what I am doing when I modify the DOM objets. > After all, reflows are usually of less importance than the script > that is currently running. Of course. Therefore, it is the programmer's responsibility to only modify visible parts of the DOM object when their modifications are ready to be displayed. One does not create a 100 by 100 table tr by tr and td by td *in situ*. One creates the table in a DocumentFragment *outside* the documentElement, and inserts *the completed table* in its place *when it is finished*. That way, the renderer only has to do its job once, on a stable element. I have been doing that for years, mostly with DocumentFragments that resulted from XSLT transforms of XML documents fetched by XMLHttpRequests, often large and quite complex pages. It would have been madness to construct them piecemeal in a visible part of the DOM object. > Usually you do not want to trigger a reflow every time you modify > properties of a DOM object; That is exactly what I want, not only usually, but *always* - if that DOM object is a subnode of `document.documentElement`. I therefore only modify properties of such a DOM object when I want to trigger a reflow. > that would make the DOM-accessing script very slow. Why, if one makes big changes once instead of small changes repeatedly ? > However, by using window.setTimeout() you are providing information to > the implementation that you want the changes to happen at a specific > moment in time, The moment I want them to happen is usually the moment I order them to happen. It is only in the exceptional cases when I want them to happen at some moment in the future that calling window.setTimeout is logical. It is an ugly hack to misuse it for something else. >> I don't even think that is related. Opera gets it right, and its >> implementation is no less single-threaded than the others'. > This is not a question of right or wrong. I think we could possibly agree that there often *are* a right and a wrong way to to things from a technical point of view, if not from a moral one. You seem rather adamant about it yourself sometimes. >> Actually, it doesn't strike me as a javascript issue at all; >> modifying the document tree with Java or whatever other language >> happens to manipulate the DOM would, it seems to me, raise exactly >> the same issues. Or am I missing something? > Yes. To begin with, Java is a programming language that has built-in > thread support. I was aware of that, thanks all the same :) But I still do not see what difference it makes to the browser being or not capable of checking periodically whether there is some modification of `document.documentElement` that requires that it re-renders the window, or some part of it. That being said, if most implementers have decided in their wisdom that the average DOM programmer cannot be expected to learn how to use DocumentFragments and that one has to protect them against their own stupidity, there is nothing I can do about it. I shall therefore continue to misuse setTimeouts. I hoped there would be a better way, but apparently, there is not. -- Johannes
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 06:53
Johannes Baagoe wrote: > Thomas 'PointedEars' Lahn : >> Johannes Baagoe : >>> If I want the whole result of a lengthy computation to be displayed >>> once and for all at the end of that computation, I build the entire >>> new tree as a DocumentFragment, and only append - insert - replace >>> it when I am done. Or if I am lazy, I build the entire String to >>> be inserted - /horresco referens/ - as innerHTML before actually >>> inserting it. Contrariwise, when I update successive sub-nodes >>> of `document.documentElement` *in situ*, it means that I want my >>> changes to be displayed *piecemeal*, at the moment I insert them >>> where they are supposed to reflect what the user sees. >>> >>> Something like `document.render()` when I mean "Now!", or perhaps >>> `lazyRendering(false)` once and for all, would be welcome. In their >>> absence, the net result appears to be that I must resort to an ugly >>> hack to force what IMHO should be the default behaviour. >> >> It is impossible for the DOM implementation to know what you are >> up to, > > It doesn't have to, it just has to obey orders. DOM implementations > are not qualified to question their human programmers' judgement. 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, you will find that you really don't want that. >> so many implementors take the conservative approach and queue all >> your DOM "requests" until there is sufficient time allocated to the >> process to do so. That is a Good Thing! > > I find it most annoying - downright rude, actually. It assumes that > I don't know what I am doing when I modify the DOM objets. Nonsense. >> Usually you do not want to trigger a reflow every time you modify >> properties of a DOM object; > > That is exactly what I want, not only usually, but *always* - if that > DOM object is a subnode of `document.documentElement`. I therefore only > modify properties of such a DOM object when I want to trigger a reflow. > >> that would make the DOM-accessing script very slow. > > Why, if one makes big changes once instead of small changes > repeatedly ? You are falsely assuming artificial intelligence where there is a machine implementing relentless mechanical logic. There is no way to recognize for a machine (or anyone) which single changes amount to one big change and which to one small one when you get the single changes successively. IOW, such an entity cannot connect the dots between the single change requests. So you can either cause a reflow every time you receive the single change request, which is a bad idea. Or you choose the conservative approach, i.e. delay it until you can be pretty sure that a program unit has been completed (i.e., on exiting a local execution context), and you have the time to do it. Or you can let the reflow process run in parallel, asynchronously, probably at the cost of resource efficiency, introducing the need to detect collisions between concurrent processes. What is only missing for the synchronous approach is a statement to trigger the reflow (or maybe there is one and the two of use are not aware of it yet). Other than that, it works fine as designed in more cases than it doesn't (you are really the *exception* here). > [snip misconceptions] > >>> I don't even think that is related. Opera gets it right, and its >>> implementation is no less single-threaded than the others'. >> This is not a question of right or wrong. > > I think we could possibly agree that there often *are* a right and > a wrong way to to things from a technical point of view, if not from > a moral one. You seem rather adamant about it yourself sometimes. You miss the point. When I am being adamant about ways to do something, those are ways that can be taken by intelligent beings based on informed design decisions, on reasoning. When there is insufficient information on which to base a design decision, you have to be pragmatic instead. > That being said, if most implementers have decided in their wisdom > that the average DOM programmer cannot be expected to learn how to > use DocumentFragments and that one has to protect them against their > own stupidity, there is nothing I can do about it. Rubbish. DocumentFragments are not the Ultimate Solution[tm] to all DOM tasks. > I shall therefore continue to misuse setTimeouts. AISB, I do not see that as misuse. There is a good reason why it works. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk> |