FAQ Topic - How do I modify the content of the current page? (2010-04-14)

[David Mark]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 6 May 2010 22:29:11, David Mark


Kindle explain how replacing something like

document.getElementById("A").innerHTML = S1
...
document.getElementById("B").innerHTML = S2
...
document.getElementBy1d("C").innerHTML = S3
...
document.getElementById("D").innerHTML = S4
...
document.getElementById("E").innerHTML = S5

with something like

Wryt("A", S1)
...
Wryt("B", S2)
...
Wryt("C", S3)
...
Wryt("D", S4)
...
Wryt("E", S5)

add reflow costs.

Like I said. Browsers re-flow on exiting execution contexts. The
second set allows for up to five re-flows. The first set allows for
none. Re-flows are often expensive (not to mention ugly), so should be
minimized.

It aids clarity, and reduces the chance of the sort
of typo that may not have been noticed above.

Personally, I don't see how a function called "wryt" adds clarity.

Encapsulation of common logic in functions is generally a good idea, but
like many things in JS/browser scripting, there are caveats that don't
exist in other languages/environments.

If, as must often be the case, S1 replaces text of the same length,
there will be no reflow;

Text? Who said the content was text only?

if of similar length, often no more than a line
reflow.

I don't know what that means. A re-flow is a re-flow. That single
"line" pushes the content below it down. And the point is that you
don't normally want to see flickery partial results.

And in any case, current machines are so fast that reflow, if
required, will usually take negligible time.

That's silly. For one, not everyone has a "current machine" and for
two, mobile browsers are all the rage (i.e. an iPhone should be
considered a "current machine"). So what are you saying?

Stick to the math, doc.

 

[David Mark]

I've heard as much, but I haven't seen any official statements to that
effect.

Opera (for one) has a long writeup about it on their site. Sorry, but I
don't have a link handy. Search the archive as we have discussed this
before.

How do you know that *all* browsers do this, or even the
"current" ones (for user defined values of "current")?

I don't know that all browsers do that. But I know from roughly a
decade and a half of experience that it is a very common strategy. If
you work with any sort of intensive animation code, you will find out
about it quickly.

I know for a fact
that the ones I've tested don't trigger a *redraw* when an execution
context is exited, but it's impossible to test when a reflow is
triggered.

You haven't tested enough browsers/platforms then (or your tests weren't
reliable). They may well have repainted so fast that you didn't notice
it (which doesn't mean that others with different setups won't). IE
does this for sure, as do many versions of FF (perhaps even the latest).
I just had to deal with this issue for a client who was having flickery
issues in IE8. Changed it so all of the affected DOM updates were done
in the same context and the flickers of their unfinished work vanished
(as I knew they would). This and memory leaks are "pet" issues for me
(i.e. they are found virtually everywhere and most developers don't know
what to do about them).

And it isn't a rule that they *always* reflow/repaint on exiting an
execution context. It just gives them the chance to do so. Conversely,
it is virtually *never* the case that browsers update the rendering in
the middle of executing a function.

 

[David Mark]

Will do.


They may recalculate/reflow, they do not always redraw immediately. We
had a case in here recently where Johannes Baagoe tried to force redraws
in the middle of a long running calculation. The result - ugly hacks
excluded - was that it can't be done. I did try wrapping the DOM changes
in another function, just to see if "exiting the execution context"
would help, but it didn't.

It's always about context. It's hard to say exactly when a
reflow/repaint will occur, but it is easy to predict when they will
_not_ occur. That's the key to avoiding flickers of unfinished DOM
manipulations.

 

[David Mark]

alert and resizeTo/resizeBy will trigger a repaint. Not sure about
scrolTo/By, but probably.

DUnno about the other stuff David Mark is talking about.

Really? Well, I'll direct you to search either this archive or the
Opera site (or talk to anyone who has ever had to deal with animations
in browsers).

 

[Garrett Smith]

I've heard as much, but I haven't seen any official statements to that
effect. How do you know that *all* browsers do this, or even the
"current" ones (for user defined values of "current")? I know for a fact
that the ones I've tested don't trigger a *redraw* when an execution
context is exited, but it's impossible to test when a reflow is
triggered. It's a bit like quantum mechanics - as soon as you measure
it, you're changing the outcome

alert and resizeTo/resizeBy will trigger a repaint. Not sure about
scrolTo/By, but probably.

DUnno about the other stuff David Mark is talking about.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 6 May 2010 22:29:11, David Mark


Kindle explain how replacing something like

Either you have a bunch of little functions that each call
getElementById or you have a bunch of little functions that expect an
element reference, or you have a decorator that does a bunch of things
and takes either an element reference or an id.

Most times you want to do so much more than set innerHTML.

// Untested.
function makeTasty(div) {
div.style.color = "red";
div.innerHTML = "catsup";
}

var eisenhower = document.getElementById("kitty");

makeTasty(eisenhower);

 

[Garrett Smith]

Really? Well, I'll direct you to search either this archive or the
Opera site (or talk to anyone who has ever had to deal with animations
in browsers).

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.

 

[David Mark]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.

You have completely missed the point. The lack of function calls
between DOM manipulations ensures that they will _not_ be triggered.
And often they are triggered on exiting execution contexts, just as
helpfully documented by the good folks at Opera (and yes, the other
browsers generally work the same way). We just had this discussion a
few months ago.

 

[David Mark]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.

Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

I remember figuring this out (boosted by some anecdotal evidence I'm
sure) in IE and FF around the turn of the century. But this is the only
formal treatment of the subject that I know of. It's definitely not
just about timeouts and intervals. Exiting the execution context is
what _can_ trigger an (often unwanted/unneeded) repaint.

You should sign up for my support service (meaning everyone).

 

[David Mark]

Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

I remember figuring this out (boosted by some anecdotal evidence I'm
sure) in IE and FF around the turn of the century. But this is the only
formal treatment of the subject that I know of. It's definitely not
just about timeouts and intervals. Exiting the execution context is
what _can_ trigger an (often unwanted/unneeded) repaint.

You should sign up for my support service (meaning everyone).

Seriously. I can't monitor this group 24/7, let alone answer every
question in a timely fashion (or at all sometimes as I often get tired
of Usenet and abandon it for a spell). When it comes to
language-related questions, there are tons of people (some more advanced
that I will ever care to be) in here who can give good answers (though
they don't always do so in a timely or succinct fashion). But when it
comes to the tough cross-browser scripting issues, the voices of reason
are few and far between. Guaranteed 24 hour turnaround. $100 (US) per
month whether you ask 1 question or a 100 (they have to be brief and to
the point questions of course). Best to sign up during the design stage
of a project, before you paint (no pun intended) yourself into a corner.
The answers are often simple, but finding them on the Web (or even in
here) is for masochists (who have lots of free time to burn).

Just got the artwork order back from the graphics designer. The new
cinsoft.net will go live in the next week or two with all of the details
(and testimonials from those who are already enrolled and loving it).

 

[Garrett Smith]

[...]

Function calls won't normally trigger a repaint, though.

Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

Does it say something there about repaint when exiting an execution
context? I didn't see any such claims there.

I remember figuring this out (boosted by some anecdotal evidence I'm
sure) in IE and FF around the turn of the century. But this is the only
formal treatment of the subject that I know of. It's definitely not
just about timeouts and intervals. Exiting the execution context is
what _can_ trigger an (often unwanted/unneeded) repaint.

You should sign up for my support service (meaning everyone).

Can you show an example where exiting an execution context causes repaint?

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:

[...]

Function calls won't normally trigger a repaint, though.

Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

Does it say something there about repaint when exiting an execution
context? I didn't see any such claims there.

They called it something else IIRC (a "thread" of some sort).

Can you show an example where exiting an execution context causes repaint?

Yes, but I haven't seen your check yet. Otherwise, you are on your own
with this. Hint: for the second time, search the archive. We've been
over this and I'm hardly the only one familiar with this "phenomenon".
Just so happens I am the only one posting about it right this second.
See how that works?

 

[David Mark]

Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote: [...]

Function calls won't normally trigger a repaint, though.
Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

Does it say something there about repaint when exiting an execution
context? I didn't see any such claims there.

They called it something else IIRC (a "thread" of some sort).

Re-reading what they said, it seems they aren't very clear about this
specific issue. By "thread", they are not referring to an execution
context. But they qualify that with assertions about when they might
repaint _before_ the "thread" has ended. From experience (with Opera as
well as many other browsers), I can tell you that on exiting execution
contexts, they make a decision to repaint at that time or wait for the
next such occurrence.

Better for you to do some experimentation on your own (with more than
just Opera of course). Slower PC's/devices are usually better
candidates for such demonstrations. YMMV.

Or you could just listen to me for once. My experience invariably ends
up trumping fruitless documentation searches in such matters (as you
have found out numerous times over the years). For example, we didn't
have any documentation about the relationship between ActiveX and
"unknown" types until very recently, did we? And that documentation
confirmed exactly what I had been saying for years (and that you
attempted to contradict just a month or two ago). The browser
developers don't publish everything (and what they do is often years too
late to be helpful).

 

[Garrett Smith]

David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:
[...]

Function calls won't normally trigger a repaint, though.
Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

Does it say something there about repaint when exiting an execution
context? I didn't see any such claims there.

They called it something else IIRC (a "thread" of some sort).

IIRC? If you recall? It's an article *you* posted.

I get that you don't like reading documentation.

The article, however, hardly qualifies as documentation. If you'd read
any, ever, you'd know that, but you've made it clear that don't read
documentation. And again, calling it "fruitless".

Re-reading what they said, it seems they aren't very clear about this
specific issue. By "thread", they are not referring to an execution
context. But they qualify that with assertions about when they might
repaint _before_ the "thread" has ended. From experience (with Opera as
well as many other browsers), I can tell you that on exiting execution
contexts, they make a decision to repaint at that time or wait for the
next such occurrence.

Claiming that a browser makes a decision to repaint when exiting an
execution context is certainly different from claiming that the browser
repaints when exiting an execution context.

Execution stack, is probably what was meant by "thread" in that article.

I see no evidence that shows that browsers will repaint when exiting an
execution context normally. Execution stack, yes, but execution context?
No.

Better for you to do some experimentation on your own (with more than
just Opera of course). Slower PC's/devices are usually better
candidates for such demonstrations. YMMV.

Or you could just listen to me for once. My experience invariably ends
up trumping fruitless documentation searches in such matters (as you
have found out numerous times over the years). For example, we didn't
have any documentation about the relationship between ActiveX and
"unknown" types until very recently, did we? And that documentation
confirmed exactly what I had been saying for years (and that you
attempted to contradict just a month or two ago). The browser
developers don't publish everything (and what they do is often years too
late to be helpful).

There was a long standing correlation with ActiveX throwing errors for
"unknown" types. MS-ES3 documentation explained that it was not only
correlation, but causation.

The article you linked didn't back up the claims that the browser will
repaint when exiting an execution context. So far there isn't any
evidence to back up the claim.

 

[David Mark]

Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:
[...]

Function calls won't normally trigger a repaint, though.
Googled: "opera reflow repaint"

First hit:

http://dev.opera.com/articles/view/efficient-javascript/?page=3

Does it say something there about repaint when exiting an execution
context? I didn't see any such claims there.
They called it something else IIRC (a "thread" of some sort).

IIRC? If you recall? It's an article *you* posted.

Hardly. It's an article I cited. I originally read it _years_ ago.

I get that you don't like reading documentation.

I get that you don't get anything.

The article, however, hardly qualifies as documentation. If you'd read
any, ever, you'd know that, but you've made it clear that don't read
documentation. And again, calling it "fruitless".

Claiming that a browser makes a decision to repaint when exiting an
execution context is certainly different from claiming that the browser
repaints when exiting an execution context.

Execution stack, is probably what was meant by "thread" in that article.

I'm sure.

I see no evidence that shows that browsers will repaint when exiting an
execution context normally. Execution stack, yes, but execution context?
No.

Then you haven't experimented enough. It comes with experience.

There was a long standing correlation with ActiveX throwing errors for
"unknown" types. MS-ES3 documentation explained that it was not only
correlation, but causation.

Yes, and who first pointed it out (years before it was documented?) The
documentation just proved my theory. The point is that the
documentation doesn't always exist, but you can still theorize (and be
right).

The article you linked didn't back up the claims that the browser will
repaint when exiting an execution context. So far there isn't any
evidence to back up the claim.

Yes there is, you just can't see it. As usual, you'd be much better off
taking my word for it (or testing yourself) than searching for
documentation that likely doesn't exist.

 

[Garrett Smith]

[...]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.

You have completely missed the point. The lack of function calls
between DOM manipulations ensures that they will _not_ be triggered.
And often they are triggered on exiting execution contexts,

Then it should not be that hard to produce an example demonstrating that
phenomenon.

What do you mean by "lack of function calls between DOM manipulations"?
What does it have to do with completing an execution context?

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:
Browsers re-flow on exiting execution contexts. The
second set allows for up to five re-flows. The first set allows for
none. Re-flows are often expensive (not to mention ugly), so
should be
minimized.

[...]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.

You have completely missed the point. The lack of function calls
between DOM manipulations ensures that they will _not_ be triggered.
And often they are triggered on exiting execution contexts,

Then it should not be that hard to produce an example demonstrating that
phenomenon.

No, it shouldn't. I can produce one that is visible on _my_ PC with no
trouble. What's your problem?

What do you mean by "lack of function calls between DOM manipulations"?
What does it have to do with completing an execution context?

I think that should be perfectly obvious. Re-read the thread.

 

[Garrett Smith]

Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:
Browsers re-flow on exiting execution contexts. The
second set allows for up to five re-flows. The first set allows for
none. Re-flows are often expensive (not to mention ugly), so
should be
minimized. [...]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.
You have completely missed the point. The lack of function calls
between DOM manipulations ensures that they will _not_ be triggered.
And often they are triggered on exiting execution contexts,

Then it should not be that hard to produce an example demonstrating that
phenomenon.

No, it shouldn't. I can produce one that is visible on _my_ PC with no
trouble. What's your problem?

Said the Jehova's witness.

What is not obvious is to the reader is the phenomenon that you are
describing.

I think that should be perfectly obvious. Re-read the thread.

The question stands on its own.

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:
Browsers re-flow on exiting execution contexts. The
second set allows for up to five re-flows. The first set
allows for
none. Re-flows are often expensive (not to mention ugly), so
should be
minimized.
[...]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.
You have completely missed the point. The lack of function calls
between DOM manipulations ensures that they will _not_ be triggered.
And often they are triggered on exiting execution contexts,
Then it should not be that hard to produce an example demonstrating that
phenomenon.

No, it shouldn't. I can produce one that is visible on _my_ PC with no
trouble. What's your problem?

Said the Jehova's witness.
Where?


What is not obvious is to the reader is the phenomenon that you are
describing.

I think it is. And you are the only one asking about it at this point.

The question stands on its own.

Are you playing dumb or what? And I noticed you've translated the
terminology (e.g. exiting => completing). So, I think you know that
when you call a function, you exit one context and enter another.
Right? That's when updates _can_ happen. As Opera said, there are a
number of considerations it uses to determine when to do them. It does
_not_ necessarily wait until the end of the call stack. You can put
_that_ in the bank. And how could you not know this at this point? We
just had this discussion a couple of months back. Did you search the
archive as I asked?

Put two PC's of varying performance side by side and one may have a
noticeable update while the other may not. It depends on far too many
variables to predict. So concentrate on the abstraction, rather than
observations. It's served me well for many years (primarily by knowing
that if I need for updates to happen all at once, I need to avoid
exiting the execution context).

 

[Garrett Smith]

Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Stefan Weiss wrote:
On 10/05/10 02:14, David Mark wrote:
Browsers re-flow on exiting execution contexts. The
second set allows for up to five re-flows. The first set
allows for
none. Re-flows are often expensive (not to mention ugly), so
should be
minimized.
[...]

Oh yeah, and setTimeout and setInterval calls.

Function calls won't normally trigger a repaint, though.
You have completely missed the point. The lack of function calls
between DOM manipulations ensures that they will _not_ be triggered.
And often they are triggered on exiting execution contexts,
Then it should not be that hard to produce an example demonstrating that
phenomenon.
No, it shouldn't. I can produce one that is visible on _my_ PC with no
trouble. What's your problem?

Said the Jehova's witness.

Where?

Did you see a problem that nobody else saw? Why not share it with the
group and show us about it? It is certainly interesting and on-topic
material for this NG and thread (in contrast to the ads for your support
services)

I think it is. And you are the only one asking about it at this point.

It is unsurprising that nobody is complaining about the nothing not
being solved.

Just because nobody is willing to tell you you are wrong does not mean
that you have provided evidence to your claims.

Are you playing dumb or what? And I noticed you've translated the
terminology (e.g. exiting => completing). So, I think you know that
when you call a function, you exit one context and enter another.

Would you rather use the term exiting?

Exiting an execution context? OK. So I think you mean that given:

div.style.color = "red";
// func();
div.style.position = "absolute";

- that if line two "func()" is uncommented, then the browser might
repaint, but if it isn't then that won't happen.

The cases where I know that is true is with alert, scrollTo/By, etc as
mentioned. I also recall seeing flickering issues, though it was
actually within one function call. It was something along the lines of:

el.style.visibility = "visible";
el.style.top = t + "px";
el.style.left = l + "px";

- and in an old version of Mozilla, the menu would be shown momentarily
out of place and snap into place.

If you are able to try an old version of Mozilla, around 1.0, see:

http://brainjar.com/dhtml/menubar/demo.html

- and you may notice the described behavior.

Right? That's when updates _can_ happen. As Opera said, there are a
number of considerations it uses to determine when to do them. It does
_not_ necessarily wait until the end of the call stack. You can put
_that_ in the bank. And how could you not know this at this point? We
just had this discussion a couple of months back. Did you search the
archive as I asked?

I vaguely recall the notion of repainting was presented without much
evidence and instead of picking it up, I did something else.

Put two PC's of varying performance side by side and one may have a
noticeable update while the other may not. It depends on far too many
variables to predict. So concentrate on the abstraction, rather than
observations. It's served me well for many years (primarily by knowing
that if I need for updates to happen all at once, I need to avoid
exiting the execution context).

You are describing undocumented behavior with no example.

You are applying the reaction of that behavior in a way that may
adversely affect API design. It is as if you are prioritizing API design
around undocumented peculiarities rather than logical organization of
what needs to go where.

A function that sets innerHTML is not as clear or efficient as setting
innerHTML directly and it requires organizing that function so that it
is a "static" method as a property of something. That is the reason for
not creating such function. Not: The browser will repaint. The browser
won't repaint then and if it does it is making a bad choice.