Can see property in NS

[Robert Bravery]

HI all,

I created a property callsed closed with in a select tag for each option.
The property is then assigned a value of 0 or 1.
I then evaluate this property in a JS script
When I do this in IE, I get the correct value either 0 or 1
But when I try the exact same thing in NS I get, an undefined message
instead. I used NS DOM inspectore to trace this. In the DOM inspector I can
see the closed property with the correct values. It is sitting right beneath
the value property, on the same level. SO it is there.
How come when run in NS the closed property is undefined but in IE it works
This is my JS:

function valid (op)
{
var amount = document.sclaim.estout.value;
var sel = 0
for (var i = 0; i < op.options.length; i++)
if (op.options[i].selected){
sel = i;
var cl = op.options[i].closed;
var status = op.options[i].text;
{alert("Not valid "+cl);}
}
}

Thanks
Robert

[VK]

Robert Bravery wrote:

HI all,

I created a property callsed closed with in a select tag for each option.
The property is then assigned a value of 0 or 1.
I then evaluate this property in a JS script
When I do this in IE, I get the correct value either 0 or 1
But when I try the exact same thing in NS I get, an undefined message
instead. I used NS DOM inspectore to trace this. In the DOM inspector I can
see the closed property with the correct values. It is sitting right beneath
the value property, on the same level. SO it is there.
It is there - in the DOM Tree. It is not there - in the DOM Interface.
That's a common mistake to mix both, because of IE's loose handling of
custom attributes. Let's say you have a div tag like:
<div id="myDIV" name="myDIV" foo="bar">Content</div>
Upon receiving this source string HTML parser creates in DOM Tree
element node DIV with attribute nodes ID="myDIV", NAME="myDIV",
FOO="bar". You can open DOM Inspector and see all these nodes.
But then you require a reference to the div element in your script, say
var d = document.getElementById("myDIV");
you are not getting element node: you are getting scriptable /DOM
Interface/ for this element. And standard-compliant UA's expose in this
interface only property /defined for the given interface/. Say DIV
element can have ID so this attribute is exposed as object property. At
the same time DIV element cannot have attributes NAME and FOO, so these
attributes are not used as object property. That creates that funny
situation you just described: then you "see" something in the tree but
"don't see" in your script.
Lucky you have tools for direct DOM Tree access: hasAttribute /
getAttribute / setAttribute. So the rule is: if you are using custom
attribute in element tag, in order to initially access them you use
getAttribute. The attributes allowed by default for the given element
are accessible right away as object properties.
var cl = op.options[i].closed;

var cl = op.options[i].getAttribute("closed");

[Richard Cornford]

Robert Bravery wrote:

I created a property callsed closed with in a select tag
for each option.
No evidence of how or where you did that is presented here. From your
wording it sounds more like you have defined a custom attribute for your
OPTION elements.

<snip> How come when run in NS the closed property is undefined
but in IE it

<snip>

So you are asking why doing something that you have not shown does not
have the results you expect it to have?

Richard.

[Robert Bravery]

HI VK,
Brilliant. Thanks for the explanations. makes perfect sense now that you
explained it correctly.
You suggestion also works perfectly

Thanks
Robert

"VK" <sc**********@yahoo.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Robert Bravery wrote:

HI all,

I created a property callsed closed with in a select tag for each option. The property is then assigned a value of 0 or 1.
I then evaluate this property in a JS script
When I do this in IE, I get the correct value either 0 or 1
But when I try the exact same thing in NS I get, an undefined message
instead. I used NS DOM inspectore to trace this. In the DOM inspector I can see the closed property with the correct values. It is sitting right beneath the value property, on the same level. SO it is there.

It is there - in the DOM Tree. It is not there - in the DOM Interface.
That's a common mistake to mix both, because of IE's loose handling of
custom attributes. Let's say you have a div tag like:
<div id="myDIV" name="myDIV" foo="bar">Content</div>
Upon receiving this source string HTML parser creates in DOM Tree
element node DIV with attribute nodes ID="myDIV", NAME="myDIV",
FOO="bar". You can open DOM Inspector and see all these nodes.
But then you require a reference to the div element in your script, say
var d = document.getElementById("myDIV");
you are not getting element node: you are getting scriptable /DOM
Interface/ for this element. And standard-compliant UA's expose in this
interface only property /defined for the given interface/. Say DIV
element can have ID so this attribute is exposed as object property. At
the same time DIV element cannot have attributes NAME and FOO, so these
attributes are not used as object property. That creates that funny
situation you just described: then you "see" something in the tree but
"don't see" in your script.
Lucky you have tools for direct DOM Tree access: hasAttribute /
getAttribute / setAttribute. So the rule is: if you are using custom
attribute in element tag, in order to initially access them you use
getAttribute. The attributes allowed by default for the given element
are accessible right away as object properties.

var cl = op.options[i].closed;

var cl = op.options[i].getAttribute("closed");

[Richard Cornford]

Robert Bravery wrote:

Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly.
Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.
You suggestion also works perfectly
Using the - getAttribute - method of Elements is the most reliable
method of retrieving custom attributes from the DOM, disregarding the
questionable wisdom of using custom attributes in the first place.
"VK" <sc**********@yahoo.com> wrote in message

<snip>

Please do not top-post to comp.lang.javascript

Richard.

[Erwin Moller]

Richard Cornford wrote:

Robert Bravery wrote:

Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly.
Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.

Hi Richard,

Can I nominate you anywhere for the 'Most Insulting Post of the Month'?
Pretty tough competition coming up for PointedEars.
;-)

Regards,
Erwin Moller

Richard.

[Richard Cornford]

Erwin Moller wrote:

Richard Cornford wrote:

Robert Bravery wrote:

Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly.

Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.

Hi Richard,

Can I nominate you anywhere for the 'Most Insulting Post of the Month'?
Pretty tough competition coming up for PointedEars.

You can if you like. However, what I wrote is true, did you look at the
nonsense VK posted?

Richard.

[Robert Bravery]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...

Robert Bravery wrote:

Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly.
Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.

Well it did work?

You suggestion also works perfectly
Using the - getAttribute - method of Elements is the most reliable
method of retrieving custom attributes from the DOM, disregarding the
questionable wisdom of using custom attributes in the first place.

I needed to create the custom attribute, because I needed it to compare
with. The select box is populated with values froma lookuip MYSQL table, it
have key values, desciption as well as a nother column called closed. This
is a single int column to stipulate whether the description pertains to a
closed or open item. So example, 'claim closed', 'claim finalised', 'claim
repudiated', are all signifying closed items.
I could not figure out how to achive this comparison, when the user selected
an status description from the select box I compare the closed values and
then take action based on that.
This allows users the ability to add other descriptions, and also the closed
or open value
Adding a custom attribute was, in my mnd the only way to achieve this,

I woul appreciate if you have a better sugestion to make.

Thanks
Robert

"VK" <sc**********@yahoo.com> wrote in message

<snip>

Please do not top-post to comp.lang.javascript

Richard.

[Robert Bravery]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...

Robert Bravery wrote:

Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly.

Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.

I would appreciate you better explanation.

Thanks
Robert

[Erwin Moller]

Richard Cornford wrote:

Erwin Moller wrote:

Richard Cornford wrote:

> Robert Bravery wrote:
>> Brilliant. Thanks for the explanations. makes perfect sense
>> now that you explained it correctly.
>
> Don't make the mistake of assuming that VK explains anything correctly.
> Mostly what he posts here are fictions with no reality beyond his own
> deranged imagination. If you believe his nonsense you will actually
> know less than before as at least then you knew that you did not know.
>
Hi Richard,

Can I nominate you anywhere for the 'Most Insulting Post of the Month'?
Pretty tough competition coming up for PointedEars.

You can if you like. However, what I wrote is true, did you look at the
nonsense VK posted?

Hi Richard,

I wasn't saying at all you were wrong.
DOM-interfacing is not my expertiece at all, so I'll take your word for it.

Your style was just... well... quite insulting. In a funny way that is.
"Don't make the mistake of assuming that VK explains anything correctly."
I don't feel too much about it, except that it made me laugh. :-)

Since I had nothing usefull to add to the discussion, I'll better shut it
up.

Regards,
Erwin Moller


Richard.

[RobG]

Robert Bravery wrote:

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...

Robert Bravery wrote:

Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly. Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.

Well it did work?

Yes, but it was the explanation that Richard took exception to.

It seems that Mozilla developers decided that non-standard HTML
attributes can't be accessed using dot properties of DOM objects.

e.g. in Firefox:

<div id="aDiv" title="the title" foo="bar"> ... </div>
<script type="text/javascript">
var aDiv = document.getElementById('aDiv');

alert(aDiv.title); // Shows 'the title'

alert(aDiv.foo); // Shows 'undefined'

</script>

However you can get the value of 'foo' using getAttribute:

alert(aDiv.getAttribute('foo')); // Shows 'bar'

As to why the Mozilla developers chose to do that, you'll need to ask
them - I think it's silly of them. IE is not the only browser that
allows the use of dot property access to non-standard attributes.

[...]
Adding a custom attribute was, in my mnd the only way to achieve this,

I woul appreciate if you have a better sugestion to make.

Another way is to put the required values in the class or title
attributes, that will create valid HTML but is likely frowned upon by
some as an abuse of those attributes. Choose your poison.
--
Rob

[Robert Bravery]

HI,
Thanks, seems to make sense.
I would suppose other browsers, like Opera, you've mentioned FireFox, etc
would behave in a similar fashion

Robert

"RobG" <rg***@iinet.net.au> wrote in message
news:44**********************@per-qv1-newsreader-01.iinet.net.au...

Robert Bravery wrote:

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...

Robert Bravery wrote:
Brilliant. Thanks for the explanations. makes perfect sense
now that you explained it correctly.
Don't make the mistake of assuming that VK explains anything correctly.
Mostly what he posts here are fictions with no reality beyond his own
deranged imagination. If you believe his nonsense you will actually
know less than before as at least then you knew that you did not know.

Well it did work?

Yes, but it was the explanation that Richard took exception to.

It seems that Mozilla developers decided that non-standard HTML
attributes can't be accessed using dot properties of DOM objects.

e.g. in Firefox:

<div id="aDiv" title="the title" foo="bar"> ... </div>
<script type="text/javascript">
var aDiv = document.getElementById('aDiv');

alert(aDiv.title); // Shows 'the title'

alert(aDiv.foo); // Shows 'undefined'

</script>

However you can get the value of 'foo' using getAttribute:

alert(aDiv.getAttribute('foo')); // Shows 'bar'

As to why the Mozilla developers chose to do that, you'll need to ask
them - I think it's silly of them. IE is not the only browser that
allows the use of dot property access to non-standard attributes.

[...]

Adding a custom attribute was, in my mnd the only way to achieve this,

I woul appreciate if you have a better sugestion to make.

Another way is to put the required values in the class or title
attributes, that will create valid HTML but is likely frowned upon by
some as an abuse of those attributes. Choose your poison.
--
Rob

[VK]

Robert Bravery wrote:

I would suppose other browsers, like Opera, you've mentioned FireFox, etc
would behave in a similar fashion.

In summary any UA that decided to follow W3C recs (or at least
pretending of doing so).

<http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-642250288>

You can file a feature request to bugzilla.mozilla.org so it would
imitate IE, but I have great doubts on success in this particular case.

[RobG]

VK wrote:

Robert Bravery wrote:

I would suppose other browsers, like Opera, you've mentioned FireFox, etc
would behave in a similar fashion.
In summary any UA that decided to follow W3C recs (or at least
pretending of doing so).

Bad guess or pure conjecture - but wrong. There are two, at least, that
claim follow the W3C DOM specifications[1] and allow dot property access
to non-standard HTML element attributes - Safari and IE.

Opera behaves the same as Mozilla.

The important part to the OP is that getAttribute works more reliably
where a variety of browsers will be encountered (e.g. the web).

<http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-642250288>

You can file a feature request to bugzilla.mozilla.org so it would
imitate IE, but I have great doubts on success in this particular case.

You might at least find out why they implemented it the way they did.
1. Noting that there probably isn't any browser that follows the
W3C specifications 100% precisely with no exception or extension.
--
Rob