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

[Paul Gorodyansky]

Hi,

Ran into the following problem while trying to have a code to
attach a Virtual Keyboard to any user's form:

User clicks a button and my JavaScript changes outerHTML
of say <textarea - adding things like ONCLICK='saveCa ret(this)'
etc. and it also tries to save any text that user could've entered
before the button press.

a) Value - (already typed text) is not assigned back
b) outerHTML is still the same - both in alert() text and via

javascript:x=do cument.body.inn erHTML.replace(/</g,'&lt;').repla ce(/\n/g,'<br>'); document.body.i nnerHTML = x;

The code is simple so I wander whether we have a way to force HTML to be
re-avaluated/re-parsed via a button click

(if I do the same via <script....</scriptline placed above the button
then everything is OK - because HTML is being changed _before_ the
page load is over)

=============== =============== =========
function vkb_addAttribut es(obj)
{

var obj_value = ""; if (obj.value != "") obj_value = obj.value;
var kA=" onFocus='vkb_tx tControl=this;' OnSelect='vkb_s aveCaret(this)' ";

var obj_HTML = obj.outerHTML;
var pos = obj_HTML.indexO f('>');
var part1 = obj_HTML.substr ing(0,pos);
var part2 = obj_HTML.substr ing(pos);
obj.outerHTML = part1 + kA + part2;

obj.value = obj_value;
}
=============== =============== ===============

Thanks,
Paul

[GLC]

In my opinion you should have a new function that combines the three
calls into one:

function myNewFunction(e ){
// get event triggerer
var targ;
if(!e) var e = window.event;
if (e.target) targ = e.target;
else if (e.srcElement) targ = e.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode ;

myFunction(targ , e); // *** from your example
x=f2(targ); // from your example ***

// since returning false will probably not stop the event from
propagating
// or bubbling up we cancel the event
// - from http://www.quirksmode.org/js/events_order.html
e.cancelBubble = true;
if (e.stopPropagat ion) e.stopPropagati on();
}

Then attach the new function as the keypress event handler.
I am assuming that 'x' is a global variable and that in your 'a'
example it would be attached to more than one textarea element/object.

Paul Gorodyansky wrote:

Hi,

GLC wrote:

...
To add an event handler: EventManager.Ad d(tmpImg, "click", saveItem,
false);
Then in the called function:
function saveItem(e){
// get target button
var targ;
if (!e) var e = window.event;
if (e.target) targ = e.target;
else if (e.srcElement) targ = e.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode ;
...

Thanks, it works - if it's just a function that I want to have in a new
eventhandler added to object, but I can not figure out what to do
if it's not

<textarea onkeypress=myFu nction(this, event)

but several things like (what to do with return ?):
a)
<textarea onkeypress={myF unction(this, event);x=f2(thi s);return false;}

or

b)
<textarea onkeypress={ return myFunction(this , event); }
--
Regards,
Paul

[Paul Gorodyansky]

Hi,

GLC wrote:

>
I am assuming that 'x' is a global variable and that in your 'a'
example it would be attached to more than one textarea element/object.

Right.

In my opinion you should have a new function that combines the three
calls into one:

Good idea, thanks!

So the only thing remains unclear to me - what to do with the things
(by Martin Honnen -
http://www.faqts.com/knowledge_base/view.phtml/aid/1661 )

where a function could return either true or false
and _it matters_ - how to have return working?

(1)
onkeypress="ret urn changeKey(this, event);">

or often there is a series of functions and then - return
statement (especially, if it's HREF simulation a button -
return false; prevents going to an URL):

Even if I combine all functions into one - what to do with
return ?

(2)
onkeypress="fCo mbined(e); return false;">


--
Regards,
Paul

[GLC]

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.
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.stopPropagat ion) e.stopPropagati on(); // won't work on IE
Or, skip the lines if the event is to continue propagating, like
returning true.

Paul Gorodyansky wrote:

Hi,

GLC wrote:

I am assuming that 'x' is a global variable and that in your 'a'
example it would be attached to more than one textarea element/object.

Right.

In my opinion you should have a new function that combines the three
calls into one:

Good idea, thanks!

So the only thing remains unclear to me - what to do with the things
(by Martin Honnen -
http://www.faqts.com/knowledge_base/view.phtml/aid/1661 )

where a function could return either true or false
and _it matters_ - how to have return working?

(1)
onkeypress="ret urn changeKey(this, event);">

or often there is a series of functions and then - return
statement (especially, if it's HREF simulation a button -
return false; prevents going to an URL):

Even if I combine all functions into one - what to do with
return ?

(2)
onkeypress="fCo mbined(e); return false;">


--
Regards,
Paul

[Paul Gorodyansky]

GLC wrote:

...
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.stopPropagat ion) e.stopPropagati on(); // 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={ret urn 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.stopPropagat ion) e.stopPropagati on(); // 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.cance lKey) // cancelKey is an internal object member
{
if (evt.preventDef ault)
evt.preventDefa ult();
return false;

What I mean is that I thought that evt.preventDefa ult 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.preventDefa ult is different
from e.cancelBubble/e.stopPropagati on()

Right?

--
Regards,
Paul

[Paul Gorodyansky]

Hi,

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

GLC wrote:

>
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.cance lKey)
{
return false;
}
where keyCheck object is instantiated here, in fnIE():

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

and insertAtCaret()
{
var caretPos = textElement.car etPos;
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.cance lKey)
{
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.ke yCode = keyCheck.newKey Code

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...
--
Regards,
Paul

[RobG]

GLC wrote:

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.stopPropagat ion) e.stopPropagati on(); // 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-Eve...preventDefault

>

W3C DOM Events Specification: stop propagation
<URL:
http://www.w3.org/TR/DOM-Level-2-Eve...topPropagation

>

--
Rob

[GLC]

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

e.preventDefaul t? e.preventDefaul t() : e.returnValue = false;

I tested this on IE6 and Firefox

Paul Gorodyansky wrote:

Hi,

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

GLC wrote:

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.cance lKey)
{
return false;
}
where keyCheck object is instantiated here, in fnIE():

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

and insertAtCaret()
{
var caretPos = textElement.car etPos;
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.cance lKey)
{
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.ke yCode = keyCheck.newKey Code

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...
--
Regards,
Paul

[RobG]

Paul Gorodyansky wrote:

GLC wrote:

...
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.stopPropagat ion) e.stopPropagati on(); // 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={ret urn 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

e.cancelBubble = true; // IE specific
if (e.stopPropagat ion) e.stopPropagati on(); // 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.cance lKey) // cancelKey is an internal object member
{
if (evt.preventDef ault)
evt.preventDefa ult();
return false;

What I mean is that I thought that evt.preventDefa ult 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.preventDef ault) {
evt.preventDefa ult();
}
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.preventDef ault) {
evt.preventDefa ult();
} else {
return false;
}

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

>

But - from your example - looks like evt.preventDefa ult is different
from e.cancelBubble/e.stopPropagati on()

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.
--
Rob

[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 wrote:

Paul Gorodyansky wrote:

GLC wrote:

...
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.stopPropagat ion) e.stopPropagati on(); // 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={ret urn 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

e.cancelBubble = true; // IE specific
if (e.stopPropagat ion) e.stopPropagati on(); // 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.cance lKey) // cancelKey is an internal object member
{
if (evt.preventDef ault)
evt.preventDefa ult();
return false;

What I mean is that I thought that evt.preventDefa ult 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.preventDef ault) {
evt.preventDefa ult();
}
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.preventDef ault) {
evt.preventDefa ult();
} else {
return false;
}

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

But - from your example - looks like evt.preventDefa ult is different
from e.cancelBubble/e.stopPropagati on()

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.
--
Rob

[RobG]

GLC wrote:

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/a...ncelbubble.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.stopPropagat ion) e.stopPropagati on();
}
</script>

<div style="border:1 px 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="stopPr op(event);">A click on this button
will not bubble up to Div A</button>
</div>
--
Rob