Is it possible to force re-avaluating/re-parsing of HTML?

[Paul Gorodyansky]

...
We have already accomlished what we wanted and no other handling needs
to occur, not even on the part of the browser.
So these lines are added, instead of returning false:
e.cancelBubble = true; // IE specific
if (e.stopPropagation) e.stopPropagation(); // won't work on IE
Or, skip the lines if the event is to continue propagating, like
returning true.

Thanks, I've almost reached the same conslusion - meaning that
the true and false from onkeypress={return foo()} from
http://www.faqts.com/knowledge_base/view.phtml/aid/1661

is the same as - from within the function -
let event to bubble (= true from FAQ) and
cancel bubbling (= false from FAQ)

Why I was confused at first after you showed me

e.cancelBubble = true; // IE specific
if (e.stopPropagation) e.stopPropagation(); // won't work on IE

is because in http://www.faqts.com/knowledge_base/view.phtml/aid/1661
they also used things like preventDefault while returning false

if (keyCheck.cancelKey) // cancelKey is an internal object member
{
if (evt.preventDefault)
evt.preventDefault();
return false;

What I mean is that I thought that evt.preventDefault is kind of
what you call "stop even bubbling" - so then why the FAQ example -
IN ADDITION - makes it to work as {return false}
if the event is already stopped?


But - from your example - looks like evt.preventDefault is different
from e.cancelBubble/e.stopPropagation()

Right?

 

[Paul Gorodyansky]

Hi,

Does not work in IE (OK in Firefox and Opera):

The whole point of returning a false is to stop the event from
"bubbling up"
So when you capture a keypress, and change what is being inserted, it
does not go ahead and insert the keypressed also.
For instance:
A textarea with an event handler has focus.
The user presses the 'a' key.
The event gets fired, captures the 'a' and the function inserts 'A'
into the textarea.
Then the event "bubbles up" and the browser inserts 'a' into the
textarea.

To prevent this senario, the event must be cancelled.

If I want to insert "xy" instead of pressed letter 'a'
("ae" instead of German 'a-umlaut' in FAQ's example):

1) in the case of return false in
<textarea onkeypress={ return checkKey(); }

works fine, that is, no 'a' appears on screen, but 'xy' does appear:

in changeKey()
....
if (keyCheck.cancelKey)
{
return false;
}


where keyCheck object is instantiated here, in fnIE():

- find that 'a' should produce 'xy' - newString
- insertAtCaret(txtControl, newString);
return { cancelKey: true }; // want to cancel the appearance of
'a'

and insertAtCaret()
{
var caretPos = textElement.caretPos;
caretPos.text = newText;
caretPos.select();
}

///////////////////////////////////

So the above works as desired.

2)
Now when I want to prevent 'a' to appear in your way -
-

var e = window.event;
e.cancelBubble = true; // IE specific

it does not work.

I've inserted it here:

if (keyCheck.cancelKey)
{
var e = window.event;
e.cancelBubble = true; // IE specific

return false;
}


It does not work - I see first "xy" on screen but then 'a' appears
there, too!

I tried to place
e.cancelBubble = true; // IE specific
_before_ calling insertAtCaret() in fnIE() but it did not help.



//////////////////////////////////////

There is no such problem with your approach if it's _one_ symbol to
be placed - because then the FAQ's code uses - for IE -
just straightforward _replacement_ -
window.event.keyCode = keyCheck.newKeyCode

and your code works fine instead of {return changeKey();}

Looks like replacement is different from preventing the key pressed
to appear and inserting an arbitrary string instead...

 

[RobG]

The whole point of returning a false is to stop the event from
"bubbling up"

Please reply below a trimmed quote of what you are replying too.
Statements made out of context leave others to guess at what you might
be referring to.

Also, please learn to quote properly so that others can see who said
what.

Your statement, taken at face value, is wrong. Returning false from an
event handler has no effect on event propagation (sometimes called
"bubbling").

So when you capture a keypress, and change what is being inserted, it
does not go ahead and insert the keypressed also.
For instance:
A textarea with an event handler has focus.
The user presses the 'a' key.
The event gets fired, captures the 'a' and the function inserts 'A'
into the textarea.
Then the event "bubbles up" and the browser inserts 'a' into the
textarea.

That is not what the term bubbling, when used with events, referrs to.
Event bubbling relates to event propagation up the DOM node tree, so
that an event from one element bubbles up to higher nodes in the tree.

Returning false from an event *does not* prevent bubbling.

To prevent this senario, the event must be cancelled.
We have already accomlished what we wanted and no other handling needs
to occur, not even on the part of the browser.
So these lines are added, instead of returning false:
e.cancelBubble = true; // IE specific
if (e.stopPropagation) e.stopPropagation(); // won't work on IE
Or, skip the lines if the event is to continue propagating, like
returning true.

Returning true or false is irrelevant for event propagation, you are
thinking of preventDefault:

W3C DOM Events Specification: Prevent default
<URL:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-preventDefault
W3C DOM Events Specification: stop propagation
<URL:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-stopPropagation

 

[GLC]

Yep, sorry. Somebody passed along some bad info.
Garbage in, garbage out ;-)
After the e.cancelBubble line, add this:

e.preventDefault? e.preventDefault() : e.returnValue = false;

I tested this on IE6 and Firefox

 

[RobG]

Thanks, I've almost reached the same conslusion - meaning that
the true and false from onkeypress={return foo()} from
http://www.faqts.com/knowledge_base/view.phtml/aid/1661

is the same as - from within the function -
let event to bubble (= true from FAQ) and
cancel bubbling (= false from FAQ)

Returning true or false to the event handler has no effect on event
propagation.

Why I was confused at first after you showed me

is because in http://www.faqts.com/knowledge_base/view.phtml/aid/1661
they also used things like preventDefault while returning false

if (keyCheck.cancelKey) // cancelKey is an internal object member
{
if (evt.preventDefault)
evt.preventDefault();
return false;

What I mean is that I thought that evt.preventDefault is kind of
what you call "stop even bubbling" - so then why the FAQ example -
IN ADDITION - makes it to work as {return false}
if the event is already stopped?

The above code could be more clearly written as:

if (evt.preventDefault) {
evt.preventDefault();
}
return false;

In other words, if preventDefault is a supported method of the event
object, call it. Then return false - which will have the same effect as
preventDefault in IE and similar browsers. For browsers like Firefox
that support both, it is like callling preventDefault twice. A more
strict version is:

if (evt.preventDefault) {
evt.preventDefault();
} else {
return false;
}

None of the above has any effect on event propagation (bubbling).

But - from your example - looks like evt.preventDefault is different
from e.cancelBubble/e.stopPropagation()

Yes, see my other post for links.

Neither "return false" or preventDefault stop propagation, only
cancelBubble (IE) and stopPropagation (W3C) can do that (which is why
the W3C created two methods: preventDefault and stopPropagation).

Most code doesn't bother with preventDefault, it just returns false
because it works in the majority of browsers. That's an observation,
not a suggestion or recommendation.

 

[GLC]

I tried cancelBubble alone and it did NOT stop propagation in IE6
Neither did returning false. I specifically has to set returnValue =
false.

 

[RobG]

I tried cancelBubble alone and it did NOT stop propagation in IE6
Neither did returning false. I specifically has to set returnValue =
false.

Please reqly below a trimmed quote of what you are replying too. I
have no idea how you attempted to use cancelBubble, if you are correct
(which I doubt) you have discovered a bug in IE that has survived
otherwise undetected for many, many years.

MSDN documentation on cancelBubble:
<URL:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/cancelbubble.asp

However, I suspect cancelBubble works as designed and that the problem
is in your code. Try this example:

<script type="text/javascript">
function stopProp(e){
// Cancel bubbling in IE
e.cancelBubble = true;
// Stop propagation in W3C browsers
if (e.stopPropagation) e.stopPropagation();
}
</script>

<div style="border:1px solid red; width: 20em;"
onclick="alert('Click received by div A');">Div A<br>
<button>A click on this button will bubble up to Div A</button>
<button onclick="stopProp(event);">A click on this button
will not bubble up to Div A</button>
</div>

 

[Paul Gorodyansky]

Yep, sorry. Somebody passed along some bad info.
Garbage in, garbage out ;-)
After the e.cancelBubble line, add this:

e.preventDefault? e.preventDefault() : e.returnValue = false;

I tested this on IE6 and Firefox

Thanks - and it makes sense now for me after Rob's and your
input - as a guy in my favorite movie "Oscar" says,
"I am getting good at this!" - I am starting to grasp the idea

 

[Paul Gorodyansky]

...
Returning true or false to the event handler has no effect on event
propagation.


Yes, see my other post for links.

Thanks, it's very helpful!