attachEvent and arguments

[luco]

Hi!
I'm having a problem with attachEvent function. I'd like to add
attachEvent dynamically to some objects so that each could execute
event function with different parameter value. The question is: how to
pass the parameter to event function?


The following code obviously doesn't work, how should i modify it to
get it to work?

for(var a=0;a<length;a++)
{
var id="item_"+a;
var obj =__document.getElementById(id);
obj.attachEvent("onclick", eventClick);
}

function eventClick()
{
alert (obj.value);
}

Unfortunately, code like this: obj.attachEvent("onclick",
eventClick(any_param)); is invalid.
I read somewhere that executing obj.attachEvent("onclick", eventClick);
automatically passes obj to eventClick function - that would be an
answer to my question but how can I use the obj inside the function?
'this.' doesn't work here..

Any ideas?

thanks in advance,
greets, Lukasz

 

[petermichaux]

for(var a=0;a<length;a++)

{
var id="item_"+a;
var obj =__document.getElementById(id);
obj.attachEvent("onclick", eventClick);
}

function eventClick()
{
alert (obj.value);
}

Unfortunately, code like this: obj.attachEvent("onclick",
eventClick(any_param)); is invalid.
I read somewhere that executing obj.attachEvent("onclick", eventClick);
automatically passes obj to eventClick function - that would be an
answer to my question but how can I use the obj inside the function?

Where did you read that?

I don't have IE fired up on my mac so this isn't tested but I think the
following should work.


for (var a=0; a<length; a++) {
var id = "item_" + a;
var obj = document.getElementById(id);
obj.attachEvent("onclick", function(){eventClick.call(obj)});
}

function eventClick() {
alert (this.value);
}


Peter

 

[RobG]

Where did you read that?

I don't have IE fired up on my mac so this isn't tested but I think the
following should work.


for (var a=0; a<length; a++) {
var id = "item_" + a;
var obj = document.getElementById(id);
obj.attachEvent("onclick", function(){eventClick.call(obj)});
}

function eventClick() {
alert (this.value);
}

No, it wont.

It is reasonable to expect that it will, but because of the use of
attachEvent and the fact that IE's event model is broken in this
regard, the function's this operator will refer to the global object,
not the DOM object.

For the OP, try this thread:

<URL:
http://groups.google.com/group/comp...vent+addeventlistener&rnum=2#6547f33093165e12
attachEvent should only be used where you are attaching more than one
event handler. If you are only attaching one, and you want to get a
reference back to the object it is attached to, the best way is:

obj.onclick = eventClick;

Note there is no '()' following the function reference. When
eventClick is called by obj's click event, its this operator will refer
to obj:

function eventClick(){
var obj = this;
if (obj.nodeName) {
alert(obj.nodeName);
} else {
alert(obj);
}
}

 

[luco]

Where did you read that?

I can't find the website now, maybe I just misunderstood.

I don't have IE fired up on my mac so this isn't tested but I think the
following should work.


for (var a=0; a<length; a++) {
var id = "item_" + a;
var obj = document.getElementById(id);
obj.attachEvent("onclick", function(){eventClick.call(obj)});
}

function eventClick() {
alert (this.value);
}

Well, unfortunately, according to passing obj by reference, function
eventClick always alerts the value of the last passed object, no matter
which object I click.
Is there a possibility to pass argument by value, not by reference, in
Javascript?

thanks, Lukasz

 

[petermichaux]

No, it wont.

It is reasonable to expect that it will, but because of the use of
attachEvent and the fact that IE's event model is broken in this
regard, the function's this operator will refer to the global object,
not the DOM object.

By "in this regard" do you mean it is only broken when obj is a DOM
object?

Thanks,
Peter

 

[RobG]

(e-mail address removed) wrote: [...]

I don't have IE fired up on my mac so this isn't tested but I think the
following should work.


for (var a=0; a<length; a++) {
var id = "item_" + a;
var obj = document.getElementById(id);
obj.attachEvent("onclick", function(){eventClick.call(obj)});
}

function eventClick() {
alert (this.value);
}

No, it wont.

It is reasonable to expect that it will, but because of the use of
attachEvent and the fact that IE's event model is broken in this
regard, the function's this operator will refer to the global object,
not the DOM object.

By "in this regard" do you mean it is only broken when obj is a DOM
object?

As far as I know, attachEvent only works with DOM objects, so yes.

IE's event model is different to the W3C model, so one could say it is
broken in other respects too but in this case it is clearly broken -
when a function is called as a method of a DOM object its this operator
should point to the DOM object, always.

IE conforms when using - objRef.eventRef = functionRef - but not for
objRef.attachEvent(eventRef, functionRef), which as far as I know
should produce an equivalent result.

Incidentally, I havn't checked IE 5.2 so I don't know if it's broken
there as well - I'll check in a couple of hours. The fact that it's
broken on IE (is it fixed in 7?) means I just never use it.

 

[Richard Cornford]

RobG wrote:

As far as I know, attachEvent only works with DOM objects,
so yes.

Microsoft's - attachEvent - is more restricted than that, as it is only
available on Elements, the Document and the window (which is not a DOM
object at all), while - addEventListener - is available on text Nodes.

IE's event model is different to the W3C model, so one could
say it is broken in other respects too

And suggest that it is not broken in this respect. The decision about
how to call the function passed to the - attachEvent - method is a
design decision made by someone at Microsoft related to a proprietary
feature of their own browser. Another decision may be seen as
potentially preferable but Microsoft had every right to make the
decision they made, and the result could not be regarded as wrong.

but in this case it is clearly broken -
when a function is called as a method of a DOM object its this
operator should point to the DOM object, always.

But with both of - attachEvent - and - addEventListenr - how the script
engine/browser actually calls the function is not visible. If the
function was called as a method then - this - should refer to the
object, but the function does not have to be called as a method, and
with - attachEvent - it clearly is not.

IE conforms when using - objRef.eventRef = functionRef - but
not for objRef.attachEvent(eventRef, functionRef), which as
far as I know should produce an equivalent result.

There is nothing to say that it should produce an equivalent result,
except that it would have been convenient for browser scriptures if it
did.

Incidentally, I havn't checked IE 5.2 so I don't know if
it's broken there as well - I'll check in a couple of hours.
The fact that it's broken on IE (is it fixed in 7?) means
I just never use it.

As it was never broken in the first place it is unlikely to be 'fixed'
in IE 7. Microsoft cannot afford to be re-defining their preparatory
browser features because they are extensively used on corporate
Intranets and breaking the tools of your more important customers is not
a viable option. It is more likely (in the long run) that they add -
addEventListener - to their browsers.

Richard.

 

[RobG]

RobG wrote:


Microsoft's - attachEvent - is more restricted than that, as it is only
available on Elements, the Document and the window (which is not a DOM
object at all), while - addEventListener - is available on text Nodes.


And suggest that it is not broken in this respect.

That was my intended meaning - just because it is sometimes different
doesn't mean it is always wrong.


[...]

Microsoft had every right to make the
decision they made, and the result could not be regarded as wrong.

It's all too easy to slip into the frame of mind that Mozilla === W3C
=== 'correct'. Thanks for the reminder.

[...]

As it was never broken in the first place it is unlikely to be 'fixed'
in IE 7. Microsoft cannot afford to be re-defining their preparatory
browser features because they are extensively used on corporate
Intranets and breaking the tools of your more important customers is not
a viable option. It is more likely (in the long run) that they add -
addEventListener - to their browsers.

When using attachEvent, is it common to use 'this' to refer to the
global/window object? I don't think it is, but my experience is
limited.

Anyhow, for the record, in IE 5.2 on Mac OS:

alert( typeof window.attachEvent );

shows 'undefined'. The same result occurs if window is replaced with
document or a DOM element so the point is moot - attachEvent seems to
be unsupported.

 

[VK]

When using attachEvent, is it common to use 'this' to refer to the
global/window object? I don't think it is, but my experience is
limited.

I thought of a missed functionality in attachEvent method a couple of
years
ago - before started to program with bindings - so I think it is time
to
correct myself.

attachEvent/detachEvent (as well as createEventObject and fireEvent)
are
method for behaviors, and they are explicetly documented as such on
MSDN.
The trick of reading here is that "for behaviors" means "inside of
behaviors",
not "in application to behaviors".

And inside of behaviors scope resolution is completely different from
the
basic Global/local one. Each behavior (binding) acts as protected
thread
with its own execution context unique for each bound element. One can
say
that besides the Global of the document we also have
Global[1]...Global[n]
Respectively behavior's event methods are thaught to think that the
relevant
context is always defined for callees (so set to the proper bound
element).
It is not attachEvent fault if it is used in the Global of the
document.

Sorry if I'm too foggy with explanations, mozilla.org and MSDN
have documents with much better English texts.

I've made a sample below. You'll need three files: index.html,
sample.htc
and sample.xml (due to syntax difference between behavior and binding).

That is a simplified to the crisp sample out of any context, so please
don't ask me why to use scripting instead of styles to highlight on
mouseover.
It is not about highlight, it is about attachEvent in IE and <this>
pointer.

addEventListener in Gecko is irrelevant to the case (in Gecko bound
element
is getting refactored events, that's another mechanics). I uncluded the
Gecko
counterpair just because I hate to post IE-only codes.

I also used reduntant <this> in statements just to make clear that
"this <this>
is not like that <this>".

Simply hover nested (2nd level) list items. Then click any of them. In
IE the
the clicked elements will start showing mouse coords while hovering
over them.
In Gecko you are just getting innerHTML of clicked elements.

Browser requirements: IE 5.5 >, Firefox 1.0 >, NN 8.0 >, Camino 1.0 >

/////////////////
// index.html

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
LI LI {
cursor: pointer;
behavior: url(sample.htc);
-moz-binding: url(sample.xml#default);
}
</style>
</head>

<body>
<ul>
<li><b>Item 1</b>
<ul>
<li>SubItem 1-1</li>
<li>SubItem 1-2</li>
<li>SubItem 1-3</li>
</ul>
</li>
<li><b>Item 2</b>
<ul>
<li>SubItem 2-1</li>
<li>SubItem 2-2</li>
<li>SubItem 2-3</li>
</ul>
</li>
<li><b>Item 3</b></li>
</ul>
</body>
</html>



/////////////////
// sample.htc

<?xml version="1.0"?>
<!--
**
* Bx2 Twinpair::HTC
* c.l.j. sample
*
-->

<public>
<component>
<implements id="sample" default="false">
<attach event="oncontentready" onevent="constructor()" />
<attach event="ondetach" onevent="destructor()" />

<attach event="onmouseover" onevent="highlight()" />
<attach event="onmouseout" onevent="restore()" />
<attach event="onclick" onevent="mouseListener()" />
</implements>
</component>


<script type="text/Jscript"><!--<![CDATA[

function constructor() {
// NOP
}

function destructor() {
// NOP
}

function highlight() {
event.cancelBubble = true;
with (this.element) {
style.color = '#0000FF';
style.fontWeight = 'bold';
// more stuff
}
}

function restore() {
event.cancelBubble = true;
with (this.element) {
style.color = '#000000';
style.fontWeight = 'normal';
// more stuff
}
}

function mouseListener() {
event.cancelBubble = true;
this.element.attachEvent('onmousemove',showCoords);
}

function showCoords() {
this.element.innerHTML = event.x + ':' + event.y;
}

//]]>--></script>


</public>



/////////////////
// sample.xml


<?xml version="1.0"?>
<!--
**
* Bx2 Twinpair::XBL
* c.l.j. sample
*
-->
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="default">
<implementation>
<constructor><![CDATA[
// NOP
]]></constructor>

<destructor><![CDATA[
// NOP
]]></destructor>
</implementation>

<handlers>
<handler event="mouseover">
event.stopPropagation();
with (this) {
style.color = '#0000FF';
style.fontWeight = 'bold';
// more stuff
}
</handler>

<handler event="mouseout">
event.stopPropagation();
with (this) {
style.color = '#000000';
style.fontWeight = 'normal';
// more stuff
}
}
</handler>

<handler event="click">
event.stopPropagation();
window.alert(this.innerHTML);
</handler>

</handlers>
</binding>
</bindings>

 

[RobG]

I can't find the website now, maybe I just misunderstood.


Well, unfortunately, according to passing obj by reference, function
eventClick always alerts the value of the last passed object, no matter
which object I click.

Because obj within the onclick function is (most probably[1]) a closure
back to obj in the function that attaches it. Therefore, whenever you
click on an element, it references obj in the function (which hangs
around because of the closure(s) ), which is set to whatever it was the
last time the enclosing function was called.

Is there a possibility to pass argument by value, not by reference, in
Javascript?

There are a couple of methods, the one suggested by petermichaux uses
the call method to augment the scope chain but doesn't fix the closure
issue. Try the following, it is a munge of mixing petermichaux's
augmentation of the scope chain using the Function's native call method
with a pattern to break the closure back to the addEvent function:


<title>Avoiding closures...</title>
<script type="text/javascript">

function addEvent(){
var el, els = document.getElementsByTagName('a');
for (var i=0, len=els.length; i<len; i++){
el = els;
if (el.attachEvent){
el.attachEvent('onclick', (function(x){
return function(){
showId.call(x);
}
})(el));
} else if (el.addEventListener) {
el.addEventListener('click', showId, true);
}
}
}

function showId(el){
alert(el.id);
}

window.onload = addEvent;

</script>

<a href="#" id="firstA">First A</a>
<a href="#" id="secondA">Second A</a>


However I have no idea how well supported the above is across browsers,
it works in IE 6 and Firefox 1.5 - please test thoroughly.

As suggested previously, if you ditch the use of attachEvent, it is
very simple to use the function's this operator to refer to the
clicked-on element:

el.onclick = showId;


And you're done - including wide cross-browser support.



1. Your original code has obj declared in a global scope, so there is
no closure, you are referencing a global variable whose value is re-set
each time the loop runs, finally ending up with the value set in the
last loop. I'm assuming that the code actually runs inside a function,
and therefore that obj will be a local variable of that function (as
per my example) and therefore that a closure will be formed. The
overall effect is the same.

 

[RobG]

I thought of a missed functionality in attachEvent method a couple of
years
ago - before started to program with bindings - so I think it is time
to
correct myself.

attachEvent/detachEvent (as well as createEventObject and fireEvent)
are
method for behaviors, and they are explicetly documented as such on
MSDN.

I don't really care for proprietary browser extensions (including those
in Mozilla, Safari, Opera, etc.). I mostly work on intranet
applications; but even there, depending on browser-specific
functionality does not seem sensible.

The biggest advantage of web-based applications is not having to deploy
a client (or at least having a sufficient client deployed by default)
almost regardless of what OS or version of OS is used. Adopting
browser-specific extensions immediately breaks that, you generally have
to be much more specific about the particular browser and version. It
also makes your developer requirements much more specific - general web
developers are much easier to find that ones that are specialised in
say XUL.

Basing intranet applications on standards compliant, cross-browser
compatibility usually ensures a kind of lowest common denominator that
greatly reduces development, deployment and support costs. It
precludes some of the fancy proprietary stuff, but at least it
maintains basic functionality - wasn't that the whole point of the WWW
in the first place?

An interesting corollary is RSS - to me, it was an attempt to get back
to a kind of basic HTML (albeit as XML), but it has been extended by
those who can't leave "simple and efficient" alone - viewing an RSS
feed is now essentially the same as viewing a web page, the "really
simple" part has been much abused.

[...]

 

[VK]

The biggest advantage of web-based applications is not having to deploy
a client (or at least having a sufficient client deployed by default)
almost regardless of what OS or version of OS is used. Adopting
browser-specific extensions immediately breaks that, you generally have
to be much more specific about the particular browser and version.

That is true and in this respect behaviors is not the same as say
var foo = 'bar';
document.forms[0].elements['txt01'].value = foo;
// Give me a script-supporting browser where
// this would fail

At the same time every single feature one currently can call as
"universally supported regardless of OS or UA" once was a proprietary
UA extension later adopted by other UA's: in order to survive the
competition. That goes starting from the client-side scripting
(JavaScript) itself which is a Netscape proprietary extension of HTML
standards.

From the most known recent samples that is IXMLHTTPRequest which was

IE's proprietary feature for years until the AJAX explosion required
from competitors either die or adopt it (you know the choice they've
made ;-)

Will XSLT, MathML, bindings, SVG ever be supported "universally
regardless of OS or UA"? Possibly will but it would take ages if
regarded as some free choice game of UA producers ("OK, guys, will we
give them this toy also or hell on them?") Things are going much
quicker - and that was proven N times already - when it's the question
of surviving in the competition. And it is not an option to stay on the
competition results achieved by the year 2006 (full cross-UA's adoption
of XMLHttpRequest and XSLT). No one is in power to say "Time, stop -
you are perfect!" Even if someone VK stops using say bindings it
will not bring any peace to producers, they still have to watch each
other and adopt on a timely manner the necessary features.

Now lesser abstractions and more practical. Behaviors do cover 97% of
visitors on servers where deployed (IE/Win, FF/Win/Mac/Ux, NN/Win,
Camino/Mac). This way the "shrink" do not exceed the regular one when
using anything atop of the most basic scripting/DOM features. For the
3% of non-capable UA's the result is exactly the same as with
JavaScript not supported/turned off and it goes by the same fall-back
schema.
That is fully satisfactory for my clients, by I readily accept the
situations when a particular UA support is a must (Safari 1.x, Safari
2.x, Opera, Konqueror, ...)
Yet a requirement to support a particular UA/ particular UA version is
more applicable to an intranet solution which has overall slightly
different specifics.

At the same time I definitely do not dare to insist on some given
browser coverage or a tools choice. It is up to the end-developers.

It also makes your developer requirements much more specific - general web
developers are much easier to find that ones that are specialised in
say XUL.

A wery right $tre$$ point
There is a bounch of scripting/DOM specialists of the most different
levels ready to make a "web-solution" (in the US nearly any male older
than 14 years).

But there is only a handfull of HTC/XBL development and compatibility
specialists so there are some benefit$ of it, at least now.
The only task is to prove the advantages of this approach to customers
which are:
1) Full freedom of features use as each behavior version is guaranted
to be processed by fully capable UA.
2) Bulletproof fall-back option w/o any extra care from the programmer
(a non-capable UA simply doesn't "see" extra page features).
3) Simplification of MDI-centric programming with one-line DOM element
extensions and calles guaranted to be used in the right scope.
4), 5) ... out of 1), 2), 3)

Ance again:
At the same time I definitely do not dare to insist on some given
browser coverage or a tools choice. It is up to the end-developers.

 

[Richard Cornford]

VK wrote:

The only task is to prove the advantages of this approach to
customers which are:

Don't forget the need to hide the disadvantages.

1) Full freedom of features use as each behavior version is guaranted
to be processed by fully capable UA.

Microsoft have released 3 versions of browsers that support behaviours,
and will be releasing another soon. If you think IE 5 and IE 7 can be
treated identically you are mad. The feature testing issues are not
removed, and feature testing alone can solve the general problem.

2) Bulletproof fall-back option w/o any extra care from the programmer
(a non-capable UA simply doesn't "see" extra page features).

Baring in mind that disabling behaviours is a user selectable security
setting in IE 7.

3) Simplification of MDI-centric programming with one-line DOM element
extensions and calles guaranted to be used in the right scope.
4), 5) ... out of 1), 2), 3)

Against the drawbacks of having to develop twice the amount of scripts
and then deploy and maintain them. More than doubling the work involved
(and so consequential costs) in order to active support on just two
browsers for what can already be achieved on many more.

Ance again:
At the same time I definitely do not dare to insist on some given
browser coverage or a tools choice. It is up to the end-developers.

As you are not taken seriously it would not matter if you did.

Richard.

 

[VK]

Don't forget the need to hide the disadvantages.

I did not hide them. Opera 8.x> and Safari 2.x> (the only UA's/versions
I do anyhow care besides the listed one) are currently excluded from
the the list of supported platforms. They will have to adapt either
Mozilla's or Microsoft's redistributable libraries.

As I said this shrink is fully acceptable for the most solutions, but
may be not for some others.

Microsoft have released 3 versions of browsers that support behaviours,
and will be releasing another soon. If you think IE 5 and IE 7 can be
treated identically you are mad.

But they are (the extra testing is already done). IE7 is running the
same JScript 5.6 version as IE6 (with lesser-minor number change,
5.6.123y instead of 5.6.123x, don't have the exact number handy right
now).
This lesser-minor reflects new XMLHttpRequest constructor added for
ActiveX-disabled secured environments. So the only change we had to
make so far is to extend HTC part of ajaxoids' consructor from say

try {
$req = new ActiveXObject('Msxml2.XMLHTTP');
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}

to:

try {
$req = new ActiveXObject('Msxml2.XMLHTTP');
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}
if (($req == null)&&('undefined' != typeof XMLHttpRequest)) {
/* in hope of IE7 or higher */
try {
$req = new XMLHttpRequest();
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}
}

Baring in mind that disabling behaviours is a user selectable security
setting in IE 7.

As well as disabling scripts themselve as well. So what's the point?
There is always a minor shrink one has to cope with.

Against the drawbacks of having to develop twice the amount of scripts
and then deploy and maintain them. More than doubling the work involved
(and so consequential costs) in order to active support on just two
browsers for what can already be achieved on many more.

It is a doubtful arguments of what is it easier to program: twice

doX();

or "once":

if (something) {
doX();
}
else if (something) {
doXSpecial();
}
else {
doNotX();
}

I put "once" in quotes because this way is effectively the same double
(triple) programming of the same thing - just joined all together in
one block.
Yet it is again an end-developers' choice to see what is more
(dis)advantageous.

 

[Richard Cornford]

I did not hide them. Opera 8.x> and Safari 2.x>
(the only UA's/versions I do anyhow care besides
the listed one)

Your inability to cope with other browsers is not a justification for
any action on the part of others.

are currently excluded from the the list of supported
platforms. They will have to adapt either Mozilla's or
Microsoft's redistributable libraries.

You expect other browser to adopt one of these systems? Well they might,
indeed some may already have done so (IceBrowser is the browser most
likely to implement behaviours, probably Konqueror/safari with Mozilla's
bindings).

As I said this shrink is fully acceptable for the most
solutions, but may be not for some others.

If you could see what nonsense that attempt at a sentence was you would
probably wish you had not said it.

But they are

But they are what? Are you saying that IEs 5 to 7 are identical? They
are not, in object model or behaivure.

(the extra testing is already done). IE7 is running the
same JScript 5.6 version as IE6 (with lesser-minor number change,
5.6.123y instead of 5.6.123x, don't have the exact number handy right
now).
This lesser-minor reflects new XMLHttpRequest constructor added for
ActiveX-disabled secured environments. So the only change we had to
make so far is to extend HTC part of ajaxoids' consructor from say

try {
$req = new ActiveXObject('Msxml2.XMLHTTP');
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}

to:

try {
$req = new ActiveXObject('Msxml2.XMLHTTP');
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}
if (($req == null)&&('undefined' != typeof XMLHttpRequest)) {
/* in hope of IE7 or higher */
try {
$req = new XMLHttpRequest();
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}
}

That is typical of your programming, you will throw an exception trying
to instantiate an ActiveX object and then try an object that can be
tested for without an exception.
Anyone who thought about it would do it the other way around.

As well as disabling scripts themselve as well.

Obviously if scripting is disabled it is redundant to be disabling
behaviours, so only script enabled and behaviour disabled permutations
are added with IE 7.

So what's the point?

Plugging security loopholes while still leaving behaviours available for
corporate Intranets that are already using them.

There is always a minor shrink one has to cope with.

That is almost as meaningless as the last time you put "shrink" in a
'sentance'.

It is a doubtful arguments of what is it easier to
program: twice

doX();

or "once":

if (something) {
doX();
}
else if (something) {
doXSpecial();
}
else {
doNotX();
}

I put "once" in quotes because this way is effectively
the same double (triple) programming of the same thing
- just joined all together in one block.

Your scripts probably do needlessly branch at every opportunity but for
people who understand cross-browser scripting only a minority of the
code branches to accommodate browsers, the rest is what must be doubled
up in your scheme.

However, even if you want to maintain that all IE version form 5 to 7
and all Mozilla/Gecko browser that implement bindings are absolute
identical (and they are certainly not) weren't you saying at the start
that other browsers can be expected to follow and implement this
technology for themselves. Doesn't that re-introduce the need for
feature testing within each of your two scripts, and possibly branching
as soon as you know how you need to branch.

That still sounds like double the work and an ongoing maintenance
headache for no tangible benefits now.

Yet it is again an end-developers' choice to see what
is more (dis)advantageous.

You still have not demonstrated anything that can be done in this way
that cannot be done with more common techniques.

Richard.

 

[VK]

Your inability to cope with other browsers is not a justification for
any action on the part of others.

Definitely not, the actions of others are *their* actions. From the
other side I would change "inability" to "lack of funding". By the
abilities I'm still capable to emulate the most sophisticated gismos
for say NN4. The trick is that no one is willing to pay me for these
hours, days and weeks of work.
So where is my personal fault? I'm living out of money they are willing
to spend, no secret fundings of any kind.

You expect other browser to adopt one of these systems? Well they might,
indeed some may already have done so (IceBrowser is the browser most
likely to implement behaviours, probably Konqueror/safari with Mozilla's
bindings).

They all will have to, they just don't know it yet

But they are what? Are you saying that IEs 5 to 7 are identical? They
are not, in object model or behaivure.

A rule of a commercial sulution is that you are responsible only for
*official* releases *currently* supported by the producer. If anyone
now say needs a IE5 or NN4.5 sulution, that will be all different
conversation with the CFO (even Mosaic 3.0 for sake of it, just let's
us put the hourly rate properly ;-)
In this aspect IE6.0 or higher is the only demand we are being payed so
far (in application to IE).

try {
$req = new ActiveXObject('Msxml2.XMLHTTP');
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}

to:

try {
$req = new ActiveXObject('Msxml2.XMLHTTP');
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}
if (($req == null)&&('undefined' != typeof XMLHttpRequest)) {
/* in hope of IE7 or higher */
try {
$req = new XMLHttpRequest();
}
catch(e) {
$err = $errors[1] + ': ' + e.message;
}
}

That is typical of your programming, you will throw an exception trying
to instantiate an ActiveX object and then try an object that can be
tested for without an exception.

Do not forget the context: that is a IE-only block in a HTC behavior.
In a conventional if-else solution I woud try to instantiate
XMLHttpRequest object first and the ActiveX counterpair only after.

Plugging security loopholes while still leaving behaviours available for
corporate Intranets that are already using them.

Based on NoScript addon downloads for Firefox I would firstly expect a
Firefox user with script support monitored rather than a IE user played
with her default (therefore optimal and hell with them) settings
altered. But my experience despite anything is limited.

That is almost as meaningless as the last time you put "shrink" in a
'sentance'.

That is a grocery/market term. In case it has no equivalent in British
English: it is an expected product loss during the
transportation/storaging/delivering due to non-controllable
curcumstances. Say 1000 pounds of candies have 5 pounds of allowed
shrink during the transportation (due to humidity change) and 50 pounds
of shop lifting shrink (people taking a candy or a handfull of candies
w/o pay). If you cannot live with this product loss (shrink), do not
sell candies.

 

[Richard Cornford]

Definitely not, the actions of others are *their* actions.

But you still continually recommend causes of action to them.

From the
other side I would change "inability" to "lack of funding".

To pay you to write cross-browser code will be expensive, not least
because you have no idea how to do it and so would spend an age
progressing by trial and error (with your inability to identify errors
seriously retarding that process). but then you should not demand that
people pay you to learn the skills you purport to sell before you will
learn them.

By the abilities I'm still capable to emulate the most sophisticated
gismos for say NN4.

But not to write a Vector emulation that works.

The trick is that no one is willing to pay me for these
hours, days and weeks of work.

No body should expect to pay you to learn to do your job.

So where is my personal fault?

That you cannot deliver? Who else could be at fault.

I'm living out of money they are willing
to spend, no secret fundings of any kind.

They all will have to, they just don't know it yet

So all that feature testing that is necessary in cross-browser
scripting must move into the XML files in your proposed system.

A rule of a commercial sulution is that you are responsible only for
*official* releases *currently* supported by the producer.

A rule in a commercial system is that you maximise the return on the
investment. Writing chaotic code that errors-out all over the place is
unlikely to achieve that.

If anyone now say needs a IE5 or NN4.5 sulution, that will be
all different conversation with the CFO (even Mosaic 3.0 for sake
of it, just let's us put the hourly rate properly ;-)

You were the one that proposed automatic clean degradation as an
inherent benefit of your system; as a result of only a limited number
of know browser loading the files. But it turns out that browsers will
be loading the file but not being accommodated by the code inside it.

In this aspect IE6.0 or higher is the only demand we are being payed
so far (in application to IE).

IE 6 can be operated with scripting disabled so clean degradation is
needed to accommodate it, and once implemented automatically covers all
pre-IE 6 versions at no extra cost.

Your concerns with cost are a product of your scripting badly to start
with. If you did a decent job of your script design there would be no
additional costs (and significantly lower maintenance costs).

Based on NoScript addon downloads for Firefox I would firstly
expect a Firefox user with script support monitored rather than
a IE user played with her default (therefore optimal and hell
with them) settings altered. But my experience despite
anything is limited.

<snip>
Hardly an unexpected reasons from you. Keep your head buried in the
sand and you may never what your poor decisions may cost your
employers.

Richard.

 

[VK]

Richard Cornford wrote:

You were the one that proposed automatic clean degradation as an
inherent benefit of your system; as a result of only a limited number
of know browser loading the files. But it turns out that browsers will
be loading the file but not being accommodated by the code inside it.

That must be a misunderstanding from your side. The browsers with XBL
(bindings) support will take their part; the browsers with HTC
(behavior) support will take their part. Others will act as if one
write "CSS rule" like foobar: !@#$%^; - such rule will be silently
ignored.

 

[Richard Cornford]

Richard Cornford wrote:



That must be a misunderstanding from your side.

You would assume that, it saves you from questioning yourself.

The browsers with XBL (bindings) support will take their part;

And include the non-latest release versions that you are not supporting
(where your code stands a chance of erroring out) and any other browser
that adopt XBL in the future (where your code erorrors out agian).

the browsers with HTC
(behavior) support will take their part.

And include the non-latest release versions that you are not supporting
(where your code stands a chance of erroring out) and any other browser
that adopt behaviours in the future (where your code erorrors out
agian).

Others will act as if one write "CSS rule" like foobar:
!@#$%^; - such rule will be silently ignored.

The failure to cleanly degrade happens on the supporting browser
versions that you are not willing to take into account, and any new
browser that adopt the technologies that you assert they must adopt.
Those re just the logical consequences of what you have written, but
being logic you will not be able to see it.

So where your three "advantages of this approach" suggested that there
would be an absolute demarcation between supporting browser and
non-supporting browser ("Bulletproof fall-back option") you were wrong
in practice because you will not code for all existing supporting
browser, and know nothing of future browsers. Where you proposed that no
feature detection will be necessary ("Full freedom of features use")
your own suggestion that other browsers will adopt the technology gives
the lie to that. And your "Simplification of MDI-centric programming"
always was a nonsense as your whole suggested strategy is at least twice
as complex of the normal approaches used by people who know what they
are doing (though maybe less complex that the chaotic mush that you pass
of as browser scripts).

Richard.