Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #19319 > unrolled thread

Accessing image property in IE when there's a period in the html ID?

Back to article view | Back to comp.lang.javascript

Contents

  Accessing image property in IE when there's a period in the html ID? Tuxedo <tuxedo@mailinator.com> - 2013-04-18 00:50 +0200
    Re: Accessing image property in IE when there's a period in the html ID? Stefan Weiss <krewecherl@gmail.com> - 2013-04-18 01:29 +0200
      Re: Accessing image property in IE when there's a period in the html ID? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-04-18 07:53 +0300
        Re: Accessing image property in IE when there's a period in the html ID? Stefan Weiss <krewecherl@gmail.com> - 2013-04-18 10:07 +0200
      Re: Accessing image property in IE when there's a period in the html ID? Tuxedo <tuxedo@mailinator.com> - 2013-04-18 08:39 +0200
      Re: Accessing image property in IE when there's a period in the html ID? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-18 11:06 +0200
        Re: Accessing image property in IE when there's a period in the html ID? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-04-18 13:05 +0300
          Re: Accessing image property in IE when there's a period in the html ID? Andrew Poulos <ap_prog@hotmail.com> - 2013-04-18 20:21 +1000
          Re: Accessing image property in IE when there's a period in the html ID? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-18 12:39 +0200
            Re: Accessing image property in IE when there's a period in the html ID? Stefan Weiss <krewecherl@gmail.com> - 2013-04-18 16:38 +0200
              Re: Accessing image property in IE when there's a period in the html ID? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-19 01:25 +0200
                Re: Accessing image property in IE when there's a period in the html ID? Stefan Weiss <krewecherl@gmail.com> - 2013-04-19 19:40 +0200
                  Re: Accessing image property in IE when there's a period in the html ID? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-19 19:52 +0200
          Re: Accessing image property in IE when there's a period in the html ID? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-04-18 13:56 +0300
            Re: Accessing image property in IE when there's a period in the html ID? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-18 13:19 +0200

#19319 — Accessing image property in IE when there's a period in the html ID?

If an image element has an html ID containing a period, such as for example:
<img src="some.jpg" id="0010.0">

Accessing it's src value in FF and other non-IE browsers may be done by:
alert(document.images["0010.0"].src);

Or if passed as an argument:
function bla(ID){
alert(document.images[ID].src);
}
bla("0010.0");

But neither the above works in IE8 for some reason. I'm not sure about IE9 
and 10 but in IE8 the resulting js-error is:
"document.images.0010.0.src' is null or not an object". 

When containig a period, how can the src (or other) value be accessed in IE?

Many thanks,
Tuxedo

[toc] | [next] | [standalone]

#19322

On 2013-04-18 00:50, Tuxedo wrote:
> If an image element has an html ID containing a period, such as for example:
> <img src="some.jpg" id="0010.0">

Just as an aside: if you use periods in id attribute values, you need to
use HTML5, because this is invalid in earlier HTML versions.

> Accessing it's src value in FF and other non-IE browsers may be done by:
> alert(document.images["0010.0"].src);
> 
> Or if passed as an argument:
> function bla(ID){
> alert(document.images[ID].src);
> }
> bla("0010.0");

Why are you using document.images? You got the id, so use
document.getElementById().

> But neither the above works in IE8 for some reason. I'm not sure about IE9 
> and 10 but in IE8 the resulting js-error is:
> "document.images.0010.0.src' is null or not an object". 
> 
> When containig a period, how can the src (or other) value be accessed in IE?

The problem is not the period, but that "0010.0" gets converted to the
numeric value 10 when you try to use it as an index for document.images.
Try the same thing with "x0010.0" and it should work as expected.

You should either use document.getElementById() or change the format of
the id values. If you absolutely want to use document.images, then
you'll need to tell IE explicitly that "0010.0" is a name, not a number:

   document.images.namedItem("0010.0");

- stefan

[toc] | [prev] | [next] | [standalone]

#19323

2013-04-18 2:29, Stefan Weiss wrote:

> On 2013-04-18 00:50, Tuxedo wrote:
>> If an image element has an html ID containing a period, such as for example:
>> <img src="some.jpg" id="0010.0">
>
> Just as an aside: if you use periods in id attribute values, you need to
> use HTML5, because this is invalid in earlier HTML versions.

The id attribute value is indeed invalid in HTML 4, but not for that 
reason. The period is allowed in id attribute values, but such a value 
must not begin with a digit, by HTML 4 rules:
http://www.w3.org/TR/REC-html40/types.html#type-id
On the other hand, this is just a formality. Browsers do what browsers 
do, actually accepting id="0010.0", and there is no "using HTML5" that 
would be needed for this. In validation, it matters which HTML version 
you validate against, but that's a different issue.

(It would be more important to remark that the markup is invalid due to 
lack of alt attribute, because this has practical impact on accessibility.)

> Why are you using document.images? You got the id, so use
> document.getElementById().

Right, but then we would not have this interesting discussion. :-)

> The problem is not the period, but that "0010.0" gets converted to the
> numeric value 10 when you try to use it as an index for document.images.

This is what actually happens in IE, as you can see by testing with a 
page that contains 11 or more <img> elements. But this is a bug in IE, 
isn't it? I can't see any justification for such a conversion in a 
property accessor. After all, document.images is not an array but an 
array-like object, and in this case it has a property named "0010.0".

>If you absolutely want to use document.images, then
> you'll need to tell IE explicitly that "0010.0" is a name, not a number:
>
>     document.images.namedItem("0010.0");

This seems to circumvent the bug - and to demonstrate that "JavaScript - 
The Definitive Guide" isn't quite accurate in practice when it says (on 
p.368 in the 6th edition) that the namedItem() method of HTMLCollection 
is not needed in JavaScript because "JavaScript programs can use array 
indexing or regular property access instead".

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#19325

On 2013-04-18 06:53, Jukka K. Korpela wrote:
> 2013-04-18 2:29, Stefan Weiss wrote:
>> On 2013-04-18 00:50, Tuxedo wrote:
>>> If an image element has an html ID containing a period, such as for example:
>>> <img src="some.jpg" id="0010.0">
>>
>> Just as an aside: if you use periods in id attribute values, you need to
>> use HTML5, because this is invalid in earlier HTML versions.
> 
> The id attribute value is indeed invalid in HTML 4, but not for that 
> reason. The period is allowed in id attribute values, but such a value 
> must not begin with a digit, by HTML 4 rules:
> http://www.w3.org/TR/REC-html40/types.html#type-id

Right, thanks.

> On the other hand, this is just a formality. Browsers do what browsers 
> do, actually accepting id="0010.0", and there is no "using HTML5" that 
> would be needed for this. In validation, it matters which HTML version 
> you validate against, but that's a different issue.

Sure, we don't have to write valid documents, and browsers will try to
make sense of whatever we throw at them. But I see validation as more
than a mere formality - it's a part of debugging: when something doesn't
work as expected, validation allows me to give up, blame the browser and
file a bug report.

>> The problem is not the period, but that "0010.0" gets converted to the
>> numeric value 10 when you try to use it as an index for document.images.
> 
> This is what actually happens in IE, as you can see by testing with a 
> page that contains 11 or more <img> elements. But this is a bug in IE, 
> isn't it? I can't see any justification for such a conversion in a 
> property accessor. After all, document.images is not an array but an 
> array-like object, and in this case it has a property named "0010.0".

It's not a bug if it's documented ;)
Unfortunately, Microsoft's DOM documentation is so grotesquely bad that
I can't even find document.images, and their page on HTMLCollection is
not very helpful.

The DOM HTMLCollection interface only specifies a length property and
item() and namedItem() accessor methods. item() is called with a numeric
index, and namedItem() with a string (id or name). What happens when the
collection is accessed like an array is up to the implementation. (This
can't be in the specification, because it's not even possible in most
languages.)

For the same reason, it's unspecified if IDs or names should show up as
properties of document.images. They do in IE8 (names are preferred over
IDs), Firefox (with both names and IDs), but not at all in Chrome.

So, my guess is that when a collection like document.images is accessed
like an array, the getter looks at the argument and decides which
accessor method to use. If the argument looks numeric, it uses item(),
otherwise it uses namedItem(). This is where IE apparently decides that
"0010.0" is numeric enough to use item().


- stefan

[toc] | [prev] | [next] | [standalone]

#19324

Stefan Weiss wrote:

> On 2013-04-18 00:50, Tuxedo wrote:
[...]
> 
> Why are you using document.images? You got the id, so use
> document.getElementById().

Good point! It works of course, also in IE.

Many thanks,
Tuxedo

[...]

[toc] | [prev] | [next] | [standalone]

#19326

Stefan Weiss wrote:

> On 2013-04-18 00:50, Tuxedo wrote:
>> Accessing it's src value in FF and other non-IE browsers may be done by:
>> alert(document.images["0010.0"].src);
>> 
>> Or if passed as an argument:
>> function bla(ID){
>> alert(document.images[ID].src);

Should be “id”, so as not to give the false impression of a constant or 
constructor.

>> }
>> bla("0010.0");
> 
> Why are you using document.images? You got the id, so use
> document.getElementById().

“document.images[…]” is probably faster than document.getElementById(…), not 
operating on as large an HTMLCollection.  It is also more precise and self-
descriptive.  

However, using an ID (“id” attribute value of “img” elements) instead of a 
name (“name” attribute value of “img” elements) is not backwards-compatible 
to DOM Level 0.

<http://docs.oracle.com/cd/E19957-01/816-6408-10/document.htm#1226315>
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-90379117>
<http://www.w3.org/TR/2012/CR-html5-20121217/dom.html#the-id-attribute>
<http://www.w3.org/TR/2012/CR-html5-20121217/dom.html#dom-document-images>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19328

2013-04-18 12:06, Thomas 'PointedEars' Lahn wrote:

> However, using an ID (“id” attribute value of “img” elements) instead of a
> name (“name” attribute value of “img” elements) is not backwards-compatible
> to DOM Level 0.

The pointless troll seems to focus on warning against good coding 
practices on the grounds of something that might happen in early 
releases of Internet Explorer 3 or Netscape Navigator 2.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#19329

On 18/04/2013 8:05 PM, Jukka K. Korpela wrote:
> 2013-04-18 12:06, Thomas 'PointedEars' Lahn wrote:
>
>> However, using an ID (“id” attribute value of “img” elements) instead
>> of a
>> name (“name” attribute value of “img” elements) is not
>> backwards-compatible
>> to DOM Level 0.
>
> The pointless troll seems to focus on warning against good coding
> practices on the grounds of something that might happen in early
> releases of Internet Explorer 3 or Netscape Navigator 2.

You just had to go out of your way to be "nasty".

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#19330

Jukka K. Korpela wrote:

> 2013-04-18 12:06, Thomas 'PointedEars' Lahn wrote:
>> However, using an ID (“id” attribute value of “img” elements) instead of
>> a name (“name” attribute value of “img” elements) is not
                                                    ^
>> backwards-compatible to DOM Level 0.
> 
> […] focus on warning against good coding
> practices on the grounds of something that might happen in early
> releases of Internet Explorer 3 or Netscape Navigator 2.

The phrase “as index” (to document.images) in the marked spot got lost on 
rewording, as the resource referred by the first URL further down (trimmed 
here by the author of the precursor) shows.

document.getElementById() was not available before Internet Explorer 5.5 
(2000-07), Netscape Navigator 6.0 (2000-11), Mozilla 0.6 (2000-12), and 
Phoenix/Firefox 0.1 (2002-09-23), to name a few.

DOM Level 1, which introduced document.getElementById(), became a W3C 
Recommendation on 1998-10-01 already, though. [1]  The term “DOM Level 0”, 
defined in hindsight in W3C DOM Level 2 HTML (that obsolotes DOM HTML 
Level 1), describes features that were *introduced* with IE 3 and NN 2, and 
by the time of NN 3 were the only *common* features of DOM implementations 
until the first two interoperable implementations of W3C DOM Level 1. [2]

Research as to where and when document.images[…] first supported IDs is 
pending, but it was probably not before IE 5.5 and NN 6.0 because that is a 
W3C DOM feature (AISB).  See also 
<http://stackoverflow.com/a/9160009/855543>.

As for “good coding practices”, it is _not_ a “good coding practice”, let 
alone best current practice, to use a method call to search a larger 
HTMLCollection when you can search a smaller one without a method call, more 
precisely, and in a less error-prone and more compatible way.

<http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/>
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/glossary.html>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19336

On 2013-04-18 12:39, Thomas 'PointedEars' Lahn wrote:
> As for “good coding practices”, it is _not_ a “good coding practice”, let 
> alone best current practice, to use a method call to search a larger 
> HTMLCollection when you can search a smaller one without a method call, more 
> precisely, and in a less error-prone and more compatible way.

How can you call document.getElementById(id) more error-prone than
document.images[id], when the topic of this very thread is an error
caused by the unexpected and poorly documented behavior of document.images?

document.getElementById(id) is standardized, well documented, and does
what it says. document.images[id] is not standardized, not well
documented, and does... well, whatever the implementation thinks it
should do. document.images is also a misnomer, because it doesn't
contain all the images in the document.

Earlier you wrote:

| “document.images[…]” is probably faster than
| document.getElementById(…), not operating on as large an
| HTMLCollection.

I doubt it. A quick one-off test showed gEBI as roughly 25x faster than
document.images in Chromium, and 2-3x faster in Firefox, Opera, and IE9.
This is anecdotal, of course, but not unexpected. gEBI is used so
frequently that it makes sense for browsers to optimize it as highly as
they can.
That gEBI is called as a method doesn't matter one bit; an access to
document.images[id] will need to invoke a hidden getter method as well.

In short, for a single element look-up by ID, I would personally not
recommend document.images over document.getElementById().

(For the sake of completeness, it should be mentioned that in earlier IE
versions and in compatibility mode, document.getElementById() used to be
case insensitive and also return elements by name.)


- stefan

[toc] | [prev] | [next] | [standalone]

#19362

Stefan Weiss wrote:

> On 2013-04-18 12:39, Thomas 'PointedEars' Lahn wrote:
>> As for “good coding practices”, it is _not_ a “good coding practice”, let
>> alone best current practice, to use a method call to search a larger
>> HTMLCollection when you can search a smaller one without a method call,
>> more precisely, and in a less error-prone and more compatible way.
> 
> How can you call document.getElementById(id) more error-prone than
> document.images[id], when the topic of this very thread is an error
> caused by the unexpected and poorly documented behavior of
> document.images?

It was not.  It was caused by using invalid markup, and DOM scripting on 
that markup.  A recipe for disaster.
 
> document.getElementById(id) is standardized, well documented,

Non sequitur.

> and does what it says. document.images[id] is not standardized,

You really need to pay more attention.  I have already showed that it is 
standardized in one W3C Specification and likely going to be standardized in 
another in the not too distant future.  If you count WHATWG HTML as a 
standard, it is specified in a second standard already.

> not well documented,

Wrong again.  I have posted references to documentation already.
Other documentation is readily available, for example

<http://msdn.microsoft.com/en-us/library/ms537461.aspx>
<https://developer.mozilla.org/en-US/docs/DOM/document.images>

> and does... well, whatever the implementation thinks it should do.

No, it does the same that it did before in the same browser.  Which is a 
part of the “problem” here.

And invalid markup aside, you should *never* use that kind of referencing (I 
dubbed it “reference worm” once) unless you are absolutely sure that the 
base value is a suitable value.  There is no difference with 
document.getElementById() there.

| The problem is not the period, but that "0010.0" gets converted to the
| numeric value 10 when you try to use it as an index for document.images.

Exactly.  This happens reproducibly in

- Netscape Navigator 3.04 (but not 4.04 and later)
- Internet Explorer 5.00.2614.3500
- Internet Explorer 5.50.4807.2300
- Internet Explorer 6.0.2800.1106

(It does not happen in Opera, Iceweasel, Chromium, or Chrome.  Other 
browsers and versions I could not or did not bother to test for the time 
being.  There is going to be a test case in the DOM Support Matrix.)

IOW, this behavior might be surprising to you, but to experienced developers 
it is well-known; in short: it is DOM Level 0-compliant.  It is no surprise 
that what you could call a bug in NN 3 is still there in IE 6 and apparently 
beyond (the OP did not post the whole markup, and which mode they used, so 
it is possible that in IE 9 Standards Mode the problem would not occur).  
Microsoft prides itself in achieving backwards compatibility in their 
products no matter the cost (figuratively); only recently (IE 10) they 
reconsidered and dropped support for several proprietary features, including 
Conditional Comments.

The error message in IE is misleading again, though, because for throwing 
the exception JScript simply concatenates the components of the 
MemberExpression with dots in the error message without regard to possible 
dots in one of the property names.

  var x = {};

  /* JScript: “'x.1.2.y' is null or not an object” */
  x["1.2"].y

| Try the same thing with "x0010.0" and it should work as expected

Because that actually *is* an ID in HTML before version 5 (because of the 
leading “x”), and cannot be interpreted as a numeric index.  The DOM 0 
implementation that we witness here again is not entirely without reason.

Also, it is not news around here that the basis of all reliable DOM 
scripting is Valid markup.  Who does not use Valid markup (or experimental 
HTML features that would need to be construed as not Valid if unsupported, 
which is all the same to a parser) should not be too surprised that their 
scripting in such a document or DOM scripting on it works unexpectedly at 
best.

IE/MSHTML 8 and 9 are _not_ HTML5-compliant, so it is no surprise that they 
would use HTML-4.01-based name resolution, even though the behavior of 
MSHTML with string indexes – which would probably be in specification lingo:

  42  Built-in properties of ElementArray instances¹

  […]

  42.21  [[Get]]

  When the [[Get]] method of an ElementArray instance /O/ is called with
  argument /index/, the following steps are taken:

    1. Let /numericIndex/ be ToInteger(/index/).
    2. If /numericIndex/ is not *NaN*,
       a. Return the result of calling the [[Item]] method of /O/ with
          argument /numericIndex/.
    3. Else, return the result of calling the [[NamedItem]] method
       of /O/ with argument ToString(/index/).

  42.22  [[Item]]

  When the [[Item]] method of an ElementArray instance /O/ is called
  with numeric argument /index/, the following steps are taken:

    1. Let /items/ be a up-to-date list of items in this instance.
    2. Let /len/ be the number of elements in /items/.
    3. If /index/ < 0 or /index/ > /len/ - 1, return *undefined*.
    2. Else,
         i.  Let /item/ be the (/index/+1)-th element in /items/.
         ii. Return /item/.

  42.23  [[NamedItem]]

  When the [[NamedItem]] method of an ElementArray instance /O/ is called
  with numeric argument /index/, the following steps are taken:

    1. Let /items/ be a up-to-date list of the items in this instance.
    2. Let /len/ be the number of elements in /items/.
    3. Let /filteredItems/ be an empty list.
    4. Let /i/ be 0.
    5. While /i/ < /len/:
         a. Let /item/ be the (/i/+1)-th element in /items/.
         b. Let /name/ be the result of calling the [[Get]] method of
            /item/ with argument "name".
         c. Let /nameEquality/ be the result of the abstract comparison
            /name/ == /index/.
         c. If /nameEquality/ is true, append /item/ to /filteredItems/.
         d. Else,
              i.   Let /id/ be the result of calling the [[Get]] method
                   of /item/ with argument "id".
              ii.  Let /idEquality/ be the result of the abstract
                   comparison /id/ == /index/.
              iii. If /idEquality/ is true, append /item/ to
                   /filteredItems/.
         e. Increase /i/ by 1.
    6. Let /filteredLength/ be the number of elements in /filteredItems/.
    7. If /filteredLength/ is 1, return the first element of
       /filteredItems/.
    8. Else, return /filteredItems/.

– is *backwards-compatible*, but not W3C-DOM-compliant (no argument there).

<http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>

________
¹  “ElementArray” is not entirely my idea; JavaScript 1.2 in Netscape
   Navigator 3.04 says “ImageArray.foo has no property 'src'” if you try to
   access document.images["foo"].src and there is no “img” element named
   “foo”.  For other collections it says “AppletArray”, “Document.FormArray”
   aso.
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19367

On 2013-04-19 01:25, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> How can you call document.getElementById(id) more error-prone than
>> document.images[id], when the topic of this very thread is an error
>> caused by the unexpected and poorly documented behavior of
>> document.images?
> 
> It was not.  It was caused by using invalid markup, and DOM scripting on 
> that markup.

That's a distortion of facts. First of all, the id value "0010.0" is
valid in HTML5. The problem as described still occurs in IE10 in
standards mode with a validated HTML5 document, so this cannot be the
main cause. Second, regardless of its validity, this value is accepted
as an ID by Internet Explorer (including IE8, the browser mentioned by
the OP). If it wasn't, various other methods including getElementById()
and namedItem() would fail.
The main cause of the problem was, as I said, that it's unclear and
poorly documented how browsers (and IE in particular) handle the
array-like access of HTML collections like document.images.

>> document.getElementById(id) is standardized, well documented,
> 
> Non sequitur.

What?

>> and does what it says. document.images[id] is not standardized,
> 
> You really need to pay more attention.  I have already showed that it is 
> standardized in one W3C Specification and likely going to be standardized in 
> another in the not too distant future.  If you count WHATWG HTML as a 
> standard, it is specified in a second standard already.
> 
>> not well documented,
> 
> Wrong again.  I have posted references to documentation already.
> Other documentation is readily available, for example
> 
> <http://msdn.microsoft.com/en-us/library/ms537461.aspx>
> <https://developer.mozilla.org/en-US/docs/DOM/document.images>

Maybe _you_ should have paid better attention. Yes, document.images is
standardized and documented, but what happens when it's directly
accessed as an array is not. That's the whole point: the accessor
methods in document.images do the right thing, the array-like access
fails in IE.

Your MDN link only refers to the W3C DOM Specification, which has
nothing at all to say about this.

The WHATWG HTML 5 specification also refers back to the W3C DOM specs
for HTMLCollections.

The MSDN link documents what happens when the index is a) an integer, or
b) the id or name of an element. The OP's case should fall squarely
under (b), but obviously that's not what happens. IE's behavior is
either a bug in the product or a bug in the documentation. Neither does
much to recommend it over getElementById().

By the way, kudos on finding that page. It's not indexed by Google. Bing
only finds some other similar pages after searching for a known phrase
from that page. I tried to look it up through the MSDN DOM reference,
but their page on 'document' doesn't have an 'images' property:

  http://msdn.microsoft.com/en-us/library/ms535862.aspx

The Microsoft documentation sites really are a train wreck. I restate
"poorly documented".

>> and does... well, whatever the implementation thinks it should do.
> 
> No, it does the same that it did before in the same browser.

So that's a "Yes".

> IOW, this behavior might be surprising to you, but to experienced developers 
> it is well-known;

As a reply to this ad hominem, I'd like to quote Tim Streater. Or Götz
von Berlichingen; less topical, but the intention is the same.

> in short: it is DOM Level 0-compliant.

There's no standard for DOM-0, so there can be no compliance. You're
describing legacy behavior.

> It is no surprise 
> that what you could call a bug in NN 3 is still there in IE 6 and apparently 
> beyond (the OP did not post the whole markup, and which mode they used, so 
> it is possible that in IE 9 Standards Mode the problem would not occur).

No, that's not possible. It's also easy enough to test, but maybe not as
much fun as speculating about what might be.

> Microsoft prides itself in achieving backwards compatibility in their 
> products no matter the cost

That's a euphemism straight out of Redmond's marketing department :)

No, I get your point: it used to work this way, they don't want to break
compatibility, and that's why it still works that way. Fine, but then
they have to document it.

> IE/MSHTML 8 and 9 are _not_ HTML5-compliant, so it is no surprise that they 
> would use HTML-4.01-based name resolution,

IE10 is, or claims to be. The problem still exists.

> even though the behavior of 
> MSHTML with string indexes – which would probably be in specification lingo:

[snip made-up specification]

> – is *backwards-compatible*, but not W3C-DOM-compliant (no argument there).

It would have been nice if they had specified it like that, but they
haven't. So we're back to

1) not standardized

    The array-like access for document.images is not specified in any
    standard.

2) poorly documented

    The implementations' documentation of this feature is either
    absent or incorrect.

3) inconsistent across implementations

    IE interprets "0010.0" as 10. Some really ancient NN versions
    may have done that, too, but most current browsers don't.

QED.

- stefan

[toc] | [prev] | [next] | [standalone]

#19368

Stefan Weiss wrote:

> On 2013-04-19 01:25, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> How can you call document.getElementById(id) more error-prone than
>>> document.images[id], when the topic of this very thread is an error
>>> caused by the unexpected and poorly documented behavior of
>>> document.images?
>> It was not.  It was caused by using invalid markup, and DOM scripting on
>> that markup.
> 
> That's a distortion of facts.

No, it is not.

> First of all, the id value "0010.0" is valid in HTML5.

We do not even know if the OP used HTML5.  You are jumping to conclusions 
again, and I am tired of it.

Microsoft does not seem to care about your layman opinion.  They seem to 
care more about backwards compatibility, or they have just neglected to fix 
this for their supposed-to-be HTML5-compliant browser.  Who knows.

> The problem as described still occurs in IE10 in standards mode with a 
> validated HTML5 document, so this cannot be the main cause.

That is correct, it is not the main cause *in IE 10*.  But the OP *did* 
*not* *use* *IE* *10*.

> Second, regardless of its validity, this value is accepted
> as an ID by Internet Explorer (including IE8, the browser mentioned by
> the OP). If it wasn't, various other methods including getElementById()
> and namedItem() would fail.

So there is another MSHTML inconsistency.  What else is new.  This does not 
mean that you should use such IDs, at least not in HTML 4.01.

> The main cause of the problem was, as I said, that it's unclear and
> poorly documented how browsers (and IE in particular) handle the
> array-like access of HTML collections like document.images.

No, the main cause was cluelessness.  But there appears to be no means to  
talk sense into you, so I will stop trying and wasting my time with you.

Score adjusted

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#19333

2013-04-18 13:05, Jukka K. Korpela wrote:

> 2013-04-18 12:06, Thomas 'PointedEars' Lahn wrote:
>
>> However, using an ID (“id” attribute value of “img” elements) instead
>> of a
>> name (“name” attribute value of “img” elements) is not
>> backwards-compatible
>> to DOM Level 0.
>
> The pointless troll seems to focus on warning against good coding
> practices on the grounds of something that might happen in early
> releases of Internet Explorer 3 or Netscape Navigator 2.

Oh, since the troll probably posts a pointless pseudo-lecture on this, 
maybe I should add this:

“Note. This attribute has been included for backwards compatibility. 
Applications should use the id attribute to identify elements.”
   Description of the “name” attribute of “img” element in HTML 4.01
   Specification, 1999,
   http://www.w3.org/TR/REC-html40/struct/objects.html#edef-IMG

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#19334

Jukka K. Korpela wrote:

> […]
> “Note. This attribute has been included for backwards compatibility.
> Applications should use the id attribute to identify elements.”
>    Description of the “name” attribute of “img” element in HTML 4.01
>    Specification, 1999,
>    http://www.w3.org/TR/REC-html40/struct/objects.html#edef-IMG

Notes are never normative.  It is one thing to write that in a specification 
for a markup language.  It is quite another to consider the implications to 
DOM implementations, and to the interoperability and efficiency of DOM 
scripting.  You learn that the hard way when you do DOM scripting as a 
professional Web developer.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web