By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,948 Members | 1,559 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,948 IT Pros & Developers. It's quick & easy.

DOM dynamically built table and addEventListener....

P: n/a
This one is driving me nuts....

var tbl = document.createElement("table");
var tbody = document.createElement("tbody");

for(var i=0; i<10; i++) {
var row = document.createElement("tr");
var curVAR = someCurrentValueOfArray[i];

row.addEventListener('click', function(e) {
alert(curVAR);
}, false);

var cell = document.createElement("td");
var cellText = document.createTextNode(i);
cell.appendChild(cellText); row.appendChild(cell);

tbody.appendChild(row);
}
tbl.appendChild(tbody);
document.getElementById('tdiv').appendChild(tbl);

====

Now... Why isn't the curVAR 'assigned' to the row-alert-function???.
if I click one of the rows, only the last curVAR (10) is alerted, but the
i-variable is nicely showed 0 to 9 in the row....

Anyone???

Thanx in advance...
Jun 27 '08 #1
Share this Question
Share on Google+
29 Replies


P: n/a
"Quarco" <do**@bother.itwrites:
This one is driving me nuts....

var tbl = document.createElement("table");
var tbody = document.createElement("tbody");

for(var i=0; i<10; i++) {
var row = document.createElement("tr");
var curVAR = someCurrentValueOfArray[i];

row.addEventListener('click', function(e) {
alert(curVAR);
}, false);

var cell = document.createElement("td");
var cellText = document.createTextNode(i);
cell.appendChild(cellText); row.appendChild(cell);

tbody.appendChild(row);
}
tbl.appendChild(tbody);
document.getElementById('tdiv').appendChild(tbl);

====

Now... Why isn't the curVAR 'assigned' to the row-alert-function???.
if I click one of the rows, only the last curVAR (10) is alerted, but the
i-variable is nicely showed 0 to 9 in the row....

Anyone???
The i and curVar variables are re-assigned in the loop (javascript
does not have block scope, only function scope), so all your event
handlers are closing over the same curVar variable, which will have
someCurrentEtc[9] as its value at the end of the loop.

You need to create a new variable to close over, by creating a new
scope:

(function(curVar) { // or make a named function and call that
row.addEventListener('click', function(e) {
alert(curVAR);
}, false);
})(curVar);
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #2

P: n/a
Quarco wrote:
>
Now... Why isn't the curVAR 'assigned' to the row-alert-function???.
if I click one of the rows, only the last curVAR (10) is alerted, but the
i-variable is nicely showed 0 to 9 in the row....
You could save curVar as a property of the element ( td / tr ) :

<html><head><script>
window.onload= function () {
var d= document,
anArray= ['a0','b1','c2','d3','e4','f5','g6','h7','i8','j9'],
y= function (p) { return d.createElement(p) },
tbody= y("tbody"),
i, cell;

for(i= 0; i< 10; i++) {
(tbody.appendChild(y('tr'))).appendChild(cell= y("td"));
cell.innerHTML= i;
cell.curVAR= anArray[i];
cell.addEventListener('click', function(e) { alert(this.curVAR) },
false);
}

(d.getElementById('tdiv').appendChild(y("table"))) .appendChild(tbody);
};
</script></head><body><div id="tdiv"></div></body></html>

--Jorge.
Jun 27 '08 #3

P: n/a
Jorge wrote:
Quarco wrote:
>Now... Why isn't the curVAR 'assigned' to the row-alert-function???.
if I click one of the rows, only the last curVAR (10) is alerted, but the
i-variable is nicely showed 0 to 9 in the row....

You could save curVar as a property of the element ( td / tr ) :
Recommended against because that would mean augmenting a host object which
is error-prone. Search the archives.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jun 27 '08 #4

P: n/a
Taking a bow...
Thank you Joost...!!!
:-)
"Joost Diepenmaat" <jo***@zeekat.nlschreef in bericht
news:87************@zeekat.nl...
"Quarco" <do**@bother.itwrites:
>This one is driving me nuts....

var tbl = document.createElement("table");
var tbody = document.createElement("tbody");

for(var i=0; i<10; i++) {
var row = document.createElement("tr");
var curVAR = someCurrentValueOfArray[i];

row.addEventListener('click', function(e) {
alert(curVAR);
}, false);

var cell = document.createElement("td");
var cellText = document.createTextNode(i);
cell.appendChild(cellText); row.appendChild(cell);

tbody.appendChild(row);
}
tbl.appendChild(tbody);
document.getElementById('tdiv').appendChild(tbl);

====

Now... Why isn't the curVAR 'assigned' to the row-alert-function???.
if I click one of the rows, only the last curVAR (10) is alerted, but the
i-variable is nicely showed 0 to 9 in the row....

Anyone???

The i and curVar variables are re-assigned in the loop (javascript
does not have block scope, only function scope), so all your event
handlers are closing over the same curVar variable, which will have
someCurrentEtc[9] as its value at the end of the loop.

You need to create a new variable to close over, by creating a new
scope:

(function(curVar) { // or make a named function and call that
row.addEventListener('click', function(e) {
alert(curVAR);
}, false);
})(curVar);
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Jun 27 '08 #5

P: n/a
On Jun 2, 8:21*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Recommended against because that would mean augmenting a host object which
is error-prone. *Search the archives.
I didn't know, and I do it all the time !
Would you please tell me why, in a few words ?
Is it a problem, specifically, of a certain browser ?
(I'll look into the archives as well, I promise)

Thanks,
--Jorge.
Jun 27 '08 #6

P: n/a
On Jun 2, 8:21*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
You could save curVar as a property of the element ( td / tr ) :

Recommended against because that would mean augmenting a host object which
is error-prone. *Search the archives.
I didn't know, and I do it all the time !
Would you tell me why is it bad, in a few words ?
(I'll look into the archive as well, I promise)

Thanks,
--Jorge.
Jun 27 '08 #7

P: n/a
Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
>Recommended against because that would mean augmenting a host object which
is error-prone. Search the archives.

I didn't know, and I do it all the time !
Tough luck.
Would you please tell me why, in a few words ?
In contrast to native objects, host objects do not need to support
augmentation. See the ECMAScript Language Specification, Edition 3 Final,
subsection "8.6.2 Internal Properties and Methods".
Is it a problem,
Yes.
specifically, of a certain browser ?
No, it can cause your Web application to break. Silently, or with an error
message. Anywhere, anytime.
(I'll look into the archives as well, I promise)
Good.
HTH

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jun 27 '08 #8

P: n/a
On Jun 2, 9:53*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
Recommended against because that would mean augmenting a host object which
is error-prone. *Search the archives.
I didn't know, and I do it all the time !

Tough luck.
Would you please tell me why, in a few words ?

In contrast to native objects, host objects do not need to support
augmentation. *See the ECMAScript Language Specification, Edition 3 Final,
subsection "8.6.2 Internal Properties and Methods".
Is it a problem,

Yes.
specifically, of a certain browser ?

No, it can cause your Web application to break. *Silently, or with an error
message. *Anywhere, anytime.
But, for example :

var y= function (p) { return document.createElement(p) },
e= y('tag');

e.property= "whatever";

Is e a "host object" ?

Or you mean :

(y('tag')).property= "whatever";

??

--Jorge.
Jun 27 '08 #9

P: n/a
Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
>[Trying to augment host objects] can cause your Web application to
break. Silently, or with an error message. Anywhere, anytime.

But, for example :

var y= function (p) { return document.createElement(p) },
This as it is does not make much sense. See our recent discussion about the
viability of Prototype.js's $() method.
e= y('tag');

e.property= "whatever";

Is e a "host object" ?
`e' is *a reference to* a host object then (probably an object that
implements an element-related interface of W3C DOM Level 2 HTML).

In ECMAScript implementations, you can only work with references to objects,
never with objects directly.
Or you mean :

(y('tag')).property= "whatever";

??
You could also write

y('tag').property = "whatever";

or

[{foo: y('tag')}][0]["foo"].property = "whatever";

and so on with the same (here: possibly disastrous) outcome. How you
construct the reference to an object makes no difference regarding the
kind of object you are referring to.

However, your second variant adds further error-proneness as y() may not
return an object reference or a primitive value convertible to an object in
which case the property lookup would then result in a TypeError (exception).

With the first variant you can at least do feature-testing on the return
value and perhaps also on the property before you attempt to assign to the
property of the object; that would generally seem to be a wise course of
action, with the exception of universally supported properties of native
objects.
Please trim your quotes.
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, <f8*******************@news.demon.co.uk>
Jun 27 '08 #10

P: n/a
On Jun 2, 11:26*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
In contrast to native objects, host objects do not need to support
augmentation. See the ECMAScript Language Specification, Edition 3 Final,
subsection "8.6.2 Internal Properties and Methods".
"Every object (including host objects) must implement the
[[Prototype]]
and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
[[HasProperty]], [[Delete]], and [[DefaultValue]] methods."

"Host objects may implement these methods in any manner unless
specified
otherwise; for example, one possibility is that [[Get]] and [[Put]]
for
a particular host object indeed fetch and store property values but
[[HasProperty]] always generates false."

Well, this is what I understand :

1- Host objects must implement the Get and Put (and others) methods.
2- The way they implement these methods is not specified ("any
manner").

I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might
not store it...

It's just that the manner in which they *do it* might be "any
manner".

And as long as a property can be read/written, does it matter in what
"manner" it's done ?

Or the problem is with any of the other methods, not with get/put ?
[Trying to augment host objects] can cause your Web application to
break. *Silently, or with an error message. *Anywhere, anytime.
Is it a certain browser that has these problems ?
(I really don't care about JS/ES outside of a browser).
How you
construct the reference to an object makes no difference regarding the
kind of object you are referring to.
You're right, I thought about it and got it (just after hitting
google's
'post' button, and before reading your post). Thanks for having the
patience to answer so well and politely.
Please trim your quotes.
(trimmed)

Thanks,
--Jorge.
Jun 27 '08 #11

P: n/a
Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
>In contrast to native objects, host objects do not need to support
augmentation. See the ECMAScript Language Specification, Edition 3
Final, subsection "8.6.2 Internal Properties and Methods".

"Every object (including host objects) must implement the [[Prototype]]
and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
[[HasProperty]], [[Delete]], and [[DefaultValue]] methods."

"Host objects may implement these methods in any manner unless specified
otherwise; for example, one possibility is that [[Get]] and [[Put]] for a
particular host object indeed fetch and store property values but
[[HasProperty]] always generates false."

Well, this is what I understand :

1- Host objects must implement the Get and Put (and others) methods.
2- The way they implement these methods is not specified ("any manner").

I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might not store
it...
But that is exactly what it means.
It's just that the manner in which they *do it* might be "any manner".
No.
And as long as a property can be read/written, does it matter in what
"manner" it's done ?
No, the "manner" may also include throwing a runtime exception. See below.
Or the problem is with any of the other methods, not with get/put ?
[[Get]] and [[Put]] are of primary concern as they are used in quite a
number of ECMAScript algorithms, particularly in those for property
accessors and assignments.
>>>[Trying to augment host objects] can cause your Web application to
break. Silently, or with an error message. Anywhere, anytime.

Is it a certain browser that has these problems ?
This is obviously impossible to say until you have tested all properties in
all known past and current browsers with all possible values. And it does
not mean anything for future versions or browsers you do not know of yet.

It is known of the MSHTML DOM that a host object in the scope chain prevents
the modification of its properties ([[Put]]) that are references to host
objects themselves (element objects for named or ID'd elements), and that
certain properties cause a runtime error on read access ([[Get]]). This is
proof that implementations do follow the specification in that regard.

Or consider the object referred to by the `style' property of element
objects in HTML DOMs. It has certain standardized and proprietary shortcut
properties for assigning CSS property values. If you assign a value to such
a property ([[Put]]) and that value is not valid for that property, you will
observe that the property does not have the assigned value but the original
value in several implementations.

Since such proof exists, it would appear to be unwise to run the risk of
breaking your script with trying to augment host objects.
(I really don't care about JS/ES outside of a browser).
However, Web browsers are only a subset of scriptable user agents.
>How you construct the reference to an object makes no difference
regarding the kind of object you are referring to.

You're right, I thought about it and got it (just after hitting google's
'post' button, and before reading your post). Thanks for having the
patience to answer so well and politely.
You are welcome.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jun 27 '08 #12

P: n/a
I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might not store
it...

But that is exactly what it means.
BTW, I found this article that you were interested in:
<news:48**************@PointedEars.de>.
There's at least one other: <news:48**************@PointedEars.de>
Still, I can't figure out why, if this is so crude, I have never had a
problem with it.
Might it be because I never program for nor test in IEs ?
If the property can be set and can be read, why isn't it safe to go on
with it ?

Is there any doc online, in the browser's libraries, or anywhere, that
says clearly "don't do this", and why not ?
(in w3c, Mozilla, MS, Opera, Webkit...)

TIA,
--Jorge.
Jun 27 '08 #13

P: n/a
Jorge wrote:
>>I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might not store
it...
But that is exactly what it means.
>BTW, I found this article that you were interested in:
<news:48**************@PointedEars.de>.
There's at least one other: <news:48**************@PointedEars.de>

Still, I can't figure out why, if this is so crude, I have never had a
problem with it.
You got away jumping a red light 999 times now.
Might it be because I never program for nor test in IEs ?
No.
If the property can be set and can be read,
If. I have showed that there are cases where this is not possible.
why isn't it safe to go on with it ?
You cannot know which execution environment your code is exposed to during
its life cycle.
Is there any doc online, in the browser's libraries, or anywhere, that
says clearly "don't do this", and why not ?
I have pointed you to the language specification already.
(in w3c, Mozilla, MS, Opera, Webkit...)
This is a feature that can be expected with conforming language
implementations. I wonder what is so difficult to understand about that.
PointedEars
Jun 27 '08 #14

P: n/a
VK
On Jun 3, 4:52 pm, Jorge <jo...@jorgechamorro.comwrote:
I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might not store
it...
But that is exactly what it means.
BTW, I found this article that you were interested in:
<news:48**************@PointedEars.de>.
There's at least one other: <news:48**************@PointedEars.de>

Still, I can't figure out why, if this is so crude, I have never had a
problem with it.
Might it be because I never program for nor test in IEs ?
If the property can be set and can be read, why isn't it safe to go on
with it ?
I would disregard whatever Thomas is saying unless it is a request for
a particular standard reference where he is pretty good. By having no
practical programming experience, he has made a credo of the type "it
doesn't fail in any place anyone knows about, but it may fail in some
place no one knows about". This gives him an opportunity for the
endless and useless pedantic rambling which is IMHO the only reason
he's posting here. For a recent sample he does believe or pretending
to believe that any script using window.onload is error prone and the
only safe alternative is using <body onload=... Sapienti sat.

For the possibility of DOM object augmentation failure you may account
expando flag state for IE. See
http://msdn.microsoft.com/en-us/library/ms533747.aspx

I never in my life saw yet this flag being used by anyone nor I even
know if it still does work, but if we decided to explore the most low
probable yet at least possible situations then here my two bucks.
Jun 27 '08 #15

P: n/a
VK wrote:
On Jun 3, 4:52 pm, Jorge <jo...@jorgechamorro.comwrote:
>>>I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might not store
it...
But that is exactly what it means.
BTW, I found this article that you were interested in:
<news:48**************@PointedEars.de>.
There's at least one other: <news:48**************@PointedEars.de>
Still, I can't figure out why, if this is so crude, I have never had a
problem with it.
Might it be because I never program for nor test in IEs ?
If the property can be set and can be read, why isn't it safe to go on
with it ?

I would disregard whatever Thomas is saying unless it is a request for
a particular standard reference where he is pretty good. By having no
^^
practical programming experience, [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ROTFL. Weren't you supposed to be somewhere else?
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Jun 27 '08 #16

P: n/a
On Jun 3, 7:35*pm, VK <schools_r...@yahoo.comwrote:
For the possibility of DOM object augmentation failure you may account
expando flag state for IE. Seehttp://msdn.microsoft.com/en-us/library/ms533747.aspx
Yep. The more I google around for this, the more convinced I am that
this "law" has to do with (yet another) buggy IE behaviour.

For example :
"* Even though it is legal to retrieve DOM objects and subsequently
storing
custom properties and attributes in them, you should not do it for
several
reasons."
(..)
"4. I won't name any names in particular, but a certain browser made
by
Microsoft does not tolerate custom properties and attributes on DOM
objects very well, particularly when the objects are added to the
DOM
dynamically and exceptions are thrown. The more elements that are
generated, the more custom properties, and the more exceptions that
are
thrown, the worse it gets."

OTOH, Safari/Webkit's automated tests check specifically that DOM
objects' *custom properties* are correctly preserved after garbage
collection :
(and that's a +2 years-old test log !)

<http://paste.lisp.org/display/20395>

+This page tests whether custom properties on DOM objects persist
after garbage collection.
+
+If the test passes, you'll see a series of 'PASS' messages below.
+
+DOM OBJECTS BEFORE GARBAGE COLLECTION:
+PASS: document.implementation.myCustomProperty should be 1 and is.
+PASS: document.myCustomProperty should be 1 and is.
+PASS: document.body.myCustomProperty should be 1 and is.
...etc.

Note, however this paragraph in the test log :

+Because neither WinIE nor FF has reasonable or predictable behavior
in this scenario, this test just documents our behavior to ensure that
we don't change it accidentally. It is not a prescription for how
things should behave.

And that, Thomas, explains why these bugs have never bitten me... :

because in Safari/WebKit, those things **work fine, as they should**.

--Jorge.
Jun 27 '08 #17

P: n/a
BTW,

Safari for Mac/Win is a free download :
<http://www.apple.com/safari/download/>

Latest nighly builds are here:
<http://nightly.webkit.org/>

:-)

--Jorge.
Jun 27 '08 #18

P: n/a
On Jun 3, 8:02*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
VK wrote:
On Jun 3, 4:52 pm, Jorge <jo...@jorgechamorro.comwrote:
>>I hope that "implement in any manner" doesn't mean that a get method
might not fetch a property's value, nor that a put method might not store
it...
But that is exactly what it means.
BTW, I found this article that you were interested in:
<news:48**************@PointedEars.de>.
There's at least one other: <news:48**************@PointedEars.de>
Still, I can't figure out why, if this is so crude, I have never had a
problem with it.
Might it be because I never program for nor test in IEs ?
If the property can be set and can be read, why isn't it safe to go on
with it ?
I would disregard whatever Thomas is saying unless it is a request for
a particular standard reference where he is pretty good. By having no

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *^^practical programming experience, [...]

* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ROTFL. *Weren't you supposed to be somewhere else?

PointedEars
Please trim your quotes...

/8¬)

--Jorge.
Jun 27 '08 #19

P: n/a
VK
On Jun 3, 10:42 pm, Jorge <jo...@jorgechamorro.comwrote:
On Jun 3, 7:35 pm, VK <schools_r...@yahoo.comwrote:
For the possibility of DOM object augmentation failure you may account
expando flag state for IE. Seehttp://msdn.microsoft.com/en-us/library/ms533747.aspx

Yep. The more I google around for this, the more convinced I am that
this "law" has to do with (yet another) buggy IE behaviour.
I'm missing the reason to call it a "bug". It is an additional flag in
Microsoft model allowing to lock/unlock "document" object
augmentation.
a certain browser made by
Microsoft does not tolerate custom properties and attributes on DOM
objects very well, particularly when the objects are added to the
DOM
dynamically and exceptions are thrown. The more elements that are
generated, the more custom properties, and the more exceptions that
are
thrown, the worse it gets."
I guess you are quoting some resource, but which one? "Microsoft does
not tolerate custom properties" is a big news for me in account of the
technology of behaviors specially made to have as many different
custom properties as one wants - besides the regular object
augmentation. Possibly the quoted source contains some explained test
cases to sustain such claim, but again: what is this source?
Jun 27 '08 #20

P: n/a
On Jun 3, 9:46*pm, VK <schools_r...@yahoo.comwrote:
On Jun 3, 10:42 pm, Jorge <jo...@jorgechamorro.comwrote:
Yep. The more I google around for this, the more convinced I am that
this "law" has to do with (yet another) buggy IE behaviour.

I'm missing the reason to call it a "bug". It is an additional flag in
Microsoft model allowing to lock/unlock "document" object
augmentation.
The "law" we were talking about is that you should not, never ever,
add/use custom properties to host objects, more specifically
to dynamically created DOM element objects.

For example, create a <liwith
e= document.createElement('li');
then attach a custom property :
e.customProperty= whatever;

I wonder, and forgot to ask, if the same rule applies to properties
created by :

e.setAttribute('customProperty', whatever);
a certain browser made by
Microsoft does not tolerate custom properties and attributes on DOM
objects very well, particularly *when the objects are added to the
DOM
dynamically and exceptions are thrown. The more elements that are
generated, the more custom properties, and the more exceptions that
are
thrown, the worse it gets."

I guess you are quoting some resource, but which one?
Tip: copy a sentence and paste it in google (enclosed in
quotes)... :-)
http://www.google.com/search?q="Microsoft+does+not+tolerate+custom"

--Jorge.
Jun 27 '08 #21

P: n/a
Jorge wrote on 03 jun 2008 in comp.lang.javascript:
On Jun 3, 9:46’pm, VK <schools_r...@yahoo.comwrote:
>>
I'm missing the reason to call it a "bug". It is an additional flag in
Microsoft model allowing to lock/unlock "document" object
augmentation.

The "law" we were talking about is that you should not, never ever,
add/use custom properties to host objects, more specifically
to dynamically created DOM element objects.
And why is that may I ask?

Any object can have custom properies, methinks.
So it stands to logic and it works.
Why that "law", and whose law?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jun 27 '08 #22

P: n/a
VK
The "law" we were talking about is that you should not, never ever,
add/use custom properties to host objects, more specifically
to dynamically created DOM element objects.
I never heard about such "law". In the way as spelled above it is
definitely plain b.s. Leaving out the casual augmentation, read about
XBL (Mozilla) and behaviors (Microsoft)
For example, create a <liwith
e= document.createElement('li');
then attach a custom property :
e.customProperty= whatever;
so what problems are we having and where with that?
I wonder, and forgot to ask, if the same rule applies to properties
created by :

e.setAttribute('customProperty', whatever);
there is not such "law" or "rule" so nothing to apply.
a certain browser made by
Microsoft does not tolerate custom properties and attributes on DOM
objects very well, particularly when the objects are added to the
DOM
dynamically and exceptions are thrown. The more elements that are
generated, the more custom properties, and the more exceptions that
are
thrown, the worse it gets."
I guess you are quoting some resource, but which one?

Tip: copy a sentence and paste it in google (enclosed in
quotes)... :-)http://www.google.com/search?q="Microsoft+does+not+tolerate+custom"
AFAICT it gives one hit to a post of someone Jason Smestad. Is it some
hugely authoritative person in Javascript programming? Who is he?
Jun 27 '08 #23

P: n/a
Jorge wrote:
[...]
Note, however this paragraph in the test log :

+Because neither WinIE nor FF has reasonable or predictable behavior
in this scenario, this test just documents our behavior to ensure that
we don't change it accidentally. It is not a prescription for how
things should behave.

And that, Thomas, explains why these bugs have never bitten me... :

because in Safari/WebKit, those things **work fine, as they should**.
Utter nonsense.
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, <f8*******************@news.demon.co.uk>
Jun 27 '08 #24

P: n/a
On Jun 3, 11:41*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

because in Safari/WebKit, those things **work fine, as they should**.

Utter nonsense.
Yes, "Utter nonsense".
I might be wrong, of course.
But can you prove that ?

Could you write a (small) code snippet that proves what you say, so
that we can see/compare its behaviour among different browsers ?
Please ?

Thanks,
--Jorge.
Jun 27 '08 #25

P: n/a
Jorge wrote:
On Jun 3, 11:41 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>>because in Safari/WebKit, those things **work fine, as they should**.
Utter nonsense.

Yes, "Utter nonsense".
I might be wrong, of course.
You *are* wrong.
But can you prove that ?
I have already proven that. The Language Specification allows host objects
to implement [[Get]] and [[Put]] as their respective implementor sees fit.
Could you write a (small) code snippet that proves what you say, so
that we can see/compare its behaviour among different browsers ?
Gladly. Which object reference, which property name, and if [[Put]], which
value?
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jun 27 '08 #26

P: n/a
On Jun 4, 9:22*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

Could you write a (small) code snippet that proves what you say, so
that we can see/compare its behaviour among different browsers ?

Gladly. *Which object reference, which property name, and if [[Put]], which
value?
It doesn't matter.
Come on.

--Jorge.

Jun 27 '08 #27

P: n/a
Jorge wrote:
On Jun 4, 9:22 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>>Could you write a (small) code snippet that proves what you say, so
that we can see/compare its behaviour among different browsers ?
Gladly. Which object reference, which property name, and if [[Put]], which
value?

It doesn't matter.
Yes, it does.
Come on.
You have still not got it.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jun 27 '08 #28

P: n/a
On Jun 4, 9:22*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Jorge wrote:
Could you write a (small) code snippet that proves what you say, so
that we can see/compare its behaviour among different browsers ?

Gladly. (..)
How is it going ?

--Jorge.
Jun 27 '08 #29

P: n/a
Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
>Jorge wrote:
>>Could you write a (small) code snippet that proves what you say, so
that we can see/compare its behaviour among different browsers ?
Gladly. (..)

How is it going ?
It went quickly into your mailbox yesterday, I hope.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Jun 27 '08 #30

This discussion thread is closed

Replies have been disabled for this discussion.