img name or ID

[TheKeith]

I heard that the name attribute is deprecated in html 4.01 strict. Is it
recommended that you use the ID attribute for images along with the
getElementById method instead of the old way? Thanks.

[Vicomte De Valmont]

I don't know if it is deprecated, it surprises me a bit for there exist a
global collection
document.images
That collection is addressed by numerical indexes or by NAME properties:
document.images["mygifName"].src
this is why if it has been deprectaed it would surprise me. yet everything
is possible...!

Yet, of course getElementById requires an ID="something".
Of course, you can use both name= and id= in an image - the name to exploit
the document.images collection, the id for getElementById or, let's say,
dhtml
ciao
Alberto Vallini
http://www.unitedscripters.com/

"TheKeith" <[e-mail]> ha scritto nel messaggio
news:JY********************@giganews.com...

I heard that the name attribute is deprecated in html 4.01 strict. Is it
recommended that you use the ID attribute for images along with the
getElementById method instead of the old way? Thanks.

[HikksNotAtHome]

>From: "TheKeith" [e-mail]

I heard that the name attribute is deprecated in html 4.01 strict. Is it
recommended that you use the ID attribute for images along with the
getElementById method instead of the old way? Thanks.

I just validated a page, with html4.01 strict, that has name attributes in the
img tags and it validated fine. So I doubt that its been deprecated. If it has,
then the validator at w3c is wrong.
--
Randy

[TheKeith]

"HikksNotAtHome" <hi************@aol.com> wrote in message
news:20***************************@mb-m27.aol.com...

From: "TheKeith" [e-mail]

I heard that the name attribute is deprecated in html 4.01 strict. Is it
recommended that you use the ID attribute for images along with the
getElementById method instead of the old way? Thanks.

I just validated a page, with html4.01 strict, that has name attributes in

the img tags and it validated fine. So I doubt that its been deprecated. If it has, then the validator at w3c is wrong.

Yeah I validated an image map where the image has a name attribute in it. I
guess I'm wrong about this one--can't remember where I heard it.

[Lasse Reichstein Nielsen]

"TheKeith" <[e-mail]> writes:

I heard that the name attribute is deprecated in html 4.01 strict.
Some uses of the name attribute are deprecated in HTML 4.01. That
means that they are removed from HTML 4.01 Strict, and not just
deprecated.
Is it recommended that you use the ID attribute for images along
with the getElementById method instead of the old way?

In HTML 4.01 Strict, if you need to name an element, other than a form
control, you should use the id attribute. It is the only available
attribute.

You can use either document.getElementsById or document.images.namedItem
to access an image in W3C DOM 2 HTML. In ECMAScript, using square brackets
is equivalent to using the namedItem method on collections.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

TheKeith wrote:

I heard that the name attribute is deprecated in html 4.01 strict.
The `name' attribute for the `img' element is _not_ deprecated:

http://www.w3.org/TR/html4/index/attributes.html#n (no `D' there at `IMG'!)
Is it recommended that you use the ID attribute for images along
with the getElementById method instead of the old way?

That's what the HTML 4.01 Specification recommends but you need to
reconsider that, depending on your target group. If you don't want
to exclude users of UAs not capable of the W3C-DOM like Netscape 4.x,
use the `name' attribute anyway since there is no other way than the
so-called "DOM Level 0"'s document.images[...] collection to access
images.
PointedEars

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

the so-called "DOM Level 0"'s document.images[...] collection to access
images.

The document.images collection is actually official DOM 2.
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-90379117>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

the so-called "DOM Level 0"'s document.images[...] collection to access
images.

The document.images collection is actually official DOM 2.
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-90379117>

Ah, thx :)
\V/ Live long and prosper

PointedEars

[Dom Leonard]

TheKeith wrote:

I heard that the name attribute is deprecated in html 4.01 strict.
No. The attribute index in the recommendation from

http://www.w3.org/TR/html401/

only shows the name attribute of the APPLET tag as being deprecated, but
this follows from the APPLET tag being deprecated. A search through
the DTD itself shows name attributes on various element types, including
IMG.

Is it recommended that you use the ID attribute for images along with the
getElementById method instead of the old way?

Yes and not necessarily.

It recommends to use id on image elements to identify them, but allows
giving them a name attribute (with the exact same value as any id
attribute provided) for backwards compatability.

The DOM2 HTML recommendation describes the document.images collection
without deprecation. It notes for backwards compatability the collection
excludes images included in the document using OBJECT tags, and
recommends using getElementsByTagName instead of document.images to
"find the images in the document". In the absence of deprecation, I take
this to imply "when the presence of images resulting from OBJECT tag
usage may be at issue".

Using getElementById to find images is perfectly acceptable.

--

Dom

[DU]

TheKeith wrote:

I heard that the name attribute is deprecated in html 4.01 strict. Is it
recommended that you use the ID attribute for images along with the
getElementById method instead of the old way? Thanks.

I recommend you only use the id attribute for <img> for 2 reasons:
- id is unique when name attribute is not
- if you ever want to convert your HTML 4.01 page to XHTML, then you're
already a step closer since "XHTML 1.0 has deprecated the name attribute
of the a, applet, form, frame, iframe, img, and map elements, and it
will be removed from XHTML in subsequent versions."
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_8

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[DU]

DU wrote:

Even the HTML 4.01 recommendation also recommends, prefers id attribute
over name attribute for <img>: "This attribute (name) has been included
for backwards compatibility. Applications should use the id attribute to
identify elements."
http://www.w3.org/TR/html401/struct/...#adef-name-IMG

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[TheKeith]

"DU" <dr*******@hot-R-E-M-O-V-E-mail.com> wrote in message
news:bn**********@news.eusc.inter.net...

DU wrote:

Even the HTML 4.01 recommendation also recommends, prefers id attribute
over name attribute for <img>: "This attribute (name) has been included
for backwards compatibility. Applications should use the id attribute to
identify elements."
http://www.w3.org/TR/html401/struct/...#adef-name-IMG

I'll use the ID attribute from now on especially since I'm learning--there's
no point in learning an old way of doing something. I might as well keep
everything uniform by using ID for everything.

[Vicomte De Valmont]

ciao
uhm why not using both? I mean an old way of doing soemthing doesn't age:
the document.images collection is an useful tool: it grants you the option
to loop throughout ALL the available images with an array already arranged.
otherwise you'd have to arrange it yourself, either patching up a collection
by repeatedly calling in document.getElementById('image101') or by
document.getElementsByTagName("A")
the former is highly unpractical, the second is much slower than just using
an object which is already within the built in arrays of a loaded document.
It is not an issue of purist vs moderns: it is that I'm suggesting: use
both - dismissing the name just because they ADDED the id feature doesn't
mean you have to give up the possibility to scan all your images with an
alrerady available collection. Again, name= is NOT deprecated.
Of course, feel free to dismiss my suggestion, but please: it is NOT a
suggestion of "old school" vs "new school": it is the suggestion that
everybody with javascript expereince would be likely to lend to you.
Of course, eventually do as you prefer. yet using two weapons instead than
one is better - we have not given up the rifle because we have the scuds.
ciao

Alberto
http://www.unitedscripters.com/

"TheKeith" <[e-mail]> ha scritto nel messaggio
news:DJ********************@giganews.com...

"DU" <dr*******@hot-R-E-M-O-V-E-mail.com> wrote in message
news:bn**********@news.eusc.inter.net...

DU wrote:

Even the HTML 4.01 recommendation also recommends, prefers id attribute
over name attribute for <img>: "This attribute (name) has been included
for backwards compatibility. Applications should use the id attribute to
identify elements."
http://www.w3.org/TR/html401/struct/...#adef-name-IMG

I'll use the ID attribute from now on especially since I'm

learning--there's no point in learning an old way of doing something. I might as well keep
everything uniform by using ID for everything.

[cwdjr]

I converted several pages from xhtml 1.0 strict to xhtml 1.1 just
after the W3C validator included xhtml 1.1. There was little change
required on most pages. And then I came to a set of linked pages that
used "name". The validator found an error for every name I used, and I
had to convert about 50 names to id. I will let the W3C speak for
itself in the following quote.:"This Appendix describes the
differences between XHTML 1.1 and XHTML 1.0 Strict. XHTML 1.1
represents a departure from both HTML 4 and XHTML 1.0. Most
significant is the removal of features that were deprecated. In
general, the strategy is to define a markup language that is rich in
structural functionality, but that relies upon style sheets for
presentation.The differences can be summarized as follows:On every
element, the lang attribute has been removed in favor of the xml:lang
attribute (as defined in [XHTMLMOD]).On the a and map elements, the
name attribute has been removed in favor of the id attribute (as
defined in [XHTMLMOD]).The "ruby" collection of elements has been
added (as defined in [RUBY])."

[Keith Bowes]

TheKeith wrote:

I heard that the name attribute is deprecated in html 4.01 strict.

It's been deprecated in XHTML 1.0 Strict, and completely removed from
XHTML 1.1. But it's still standard in HTML 4.01.

[Thomas 'PointedEars' Lahn]

cwdjr wrote:

I converted several pages from xhtml 1.0 strict to xhtml 1.1 just
after the W3C validator included xhtml 1.1.
Look into my signature, baby ;-)

XHTML is still not recommended to be used instead of HTML 4.01, unless you
actually use XML applications like MathML, SVG, Ruby aso. or write for an
intranet:

http://groups.google.com/gr*********...x.com%3E&hl=de

The thread may be old, but what Alan J. Flavell states there is still valid.
See also

http://www.hut.fi/u/hsivonen/xhtml-the-point
There was little change required on most pages.
Of course, because you only upgraded to a newer version of the same markup
language. HTML and XHTML are similar, but one is an SGML and the other an
XML application. Do not compare apples with pears.
And then I came to a set of linked pages that used "name".
The validator found an error for every name I used, and I
had to convert about 50 names to id.

Non sequitur. There are more differences between HTML and XHTML, and we are
talking about valid HTML 4.01 Strict here. If the `name' attribute becomes a
problem while converting to XHTML and if you had valid HTML 4.01 before, a
simple search-and-replace will do the trick, since values of the `name' and
the `id' attribute share the same namespace.
X-Post & F'up2 comp.infosystems.www.authoring.html

PointedEars

[Thomas 'PointedEars' Lahn]

cwdjr wrote:

I converted several pages from xhtml 1.0 strict to xhtml 1.1 just after
the W3C validator included xhtml 1.1.
Look into my signature, baby ;-)

XHTML is still not recommended to be used instead of HTML 4.01, unless you
actually use XML applications like MathML, SVG, Ruby aso. or write for an
intranet:

http://groups.google.com/gr*********...x.com%3E&hl=de

The thread may be old, but what Alan J. Flavell states there is still valid.
See also

http://www.hut.fi/u/hsivonen/xhtml-the-point
There was little change required on most pages.
Of course, because you only upgraded to a newer version of the same markup
language. HTML and XHTML are similar, but one is an SGML and the other an
XML application. Do not compare apples with pears.
And then I came to a set of linked pages that used "name". The validator
found an error for every name I used, and I had to convert about 50 names
to id.

Non sequitur. There are more differences between HTML and XHTML, and we are
talking about valid HTML 4.01 Strict here. If the `name' attribute becomes a
problem while converting to XHTML and if you had valid HTML 4.01 before, a
simple search-and-replace will do the trick, since values of the `name' and
the `id' attribute share the same namespace.
X-Post & F'up2 comp.infosystems.www.authoring.html

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Dr John Stockton]

JRS: In article <20***************************@mb-m27.aol.com>, seen in
news:comp.lang.javascript, HikksNotAtHome <hi************@aol.com>
posted at Sun, 26 Oct 2003 20:47:42 :-

From: "TheKeith" [e-mail]

I heard that the name attribute is deprecated in html 4.01 strict. Is it
recommended that you use the ID attribute for images along with the
getElementById method instead of the old way? Thanks.

I just validated a page, with html4.01 strict, that has name attributes in the
img tags and it validated fine. So I doubt that its been deprecated. If it has,
then the validator at w3c is wrong.

Deprecated does not mean invalid; it can be used to imply something
about future validity.

In validation, deprecated features should be accepted, but might give
warnings, which could be optional.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk / ??*********@physics.org ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

[DU]

Vicomte De Valmont wrote:

ciao
uhm why not using both? I mean an old way of doing soemthing doesn't age:
the document.images collection is an useful tool: it grants you the option
to loop throughout ALL the available images with an array already arranged.
An old way of doing something does not age if it is not deprecated. Name
attribute for <img> is deprecated in XHTML; accessing the collection
document.images is not deprecated in XHTML. So there is no contradiction
here.
otherwise you'd have to arrange it yourself, either patching up a collection
by repeatedly calling in document.getElementById('image101') or by
document.getElementsByTagName("A")
the former is highly unpractical
What's highly unpractical when using, calling, resorting to an attribute
with a single, unique attribute value in a document?
The facts are:
1- document.getElementsByName is slower and more memory demanding than
document.getElementById
2- document.getElementById is better supported by browsers, more
reliable, more recommendable and more relevant than
document.getElementsByName
http://www.xs4all.nl/~ppk/js/w3c_core.html#fourmethods
http://www.xs4all.nl/~ppk/js/w3c_cor...#miscellaneous
http://www.xs4all.nl/~ppk/js/w3c/named.html
http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-71555259

, the second is much slower than just using an object which is already within the built in arrays of a loaded document.
The issue was name versus id for <img>. The issue was not id versus
collection of tagname. The subject line for this thread was clear.
It is not an issue of purist vs moderns: it is that I'm suggesting: use
both - dismissing the name just because they ADDED the id feature doesn't
mean you have to give up the possibility to scan all your images with an
alrerady available collection. Again, name= is NOT deprecated.
Again, name for <img> (and for several other elements) is deprecated in
XHTML 1.

In HTML 4, name vs id for <a> is a different issue:
"Use id or name? Authors should consider the following issues when
deciding whether to use id or name for an anchor name:
* The id attribute can act as more than just an anchor name (e.g.,
style sheet selector, processing identifier, etc.).
* Some older user agents don't support anchors created with the id
attribute.
* The name attribute allows richer anchor names (with entities)."
http://www.w3.org/TR/REC-html40/stru...#idx-anchor-10
Of course, feel free to dismiss my suggestion, but please: it is NOT a
suggestion of "old school" vs "new school": it is the suggestion that
everybody with javascript expereince would be likely to lend to you.
Of course, eventually do as you prefer. yet using two weapons instead than
one is better - we have not given up the rifle because we have the scuds.
ciao

Alberto
http://www.unitedscripters.com/

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[Vicomte De Valmont]

"DU" <dr*******@hot-R-E-M-O-V-E-mail.com> ha

Vicomte De Valmont wrote:

uhm why not using both? I mean an old way of doing > > soemthing doesn't age:

An old way of doing something does not age if it is not > deprecated. Name
As J.P. Sartre said of those who said that we can do without literature: "of
course we can do without literature - we can do even better, we can do
without mankind".
So, if we should not do without a method simply because it is aged (my
point) we should then do without it when it is deprecated (your point): but
we can do even better than that: we can wait and do without it when it is no
longer included in the interpreters - uh, what do you think? Just following
your algo-rhythm here.
attribute for <img> is deprecated in XHTML; accessing the collection
document.images is not deprecated in XHTML. So there is no contradiction
here.
I was answering to an user who saw the contradiction - you're mistaking me
for him: because the COLLECTION can be addrsssed by NAME:
You know my expert friend:
<img name="foo" src="d.jpg">
<script>salert(document.images["foo"].src);</script>

Or maybe you were not aware that collections can be addressed by the name
porperties too besides than with numbers...

I was just following the flow of his own puzzlement - I myself don't see the
contradiction (to the degree I sponsor using both): he saw the contradiction
and I suggested (with an avergae dose of statements like "Of course, feel
free to dismiss my suggestion" and "Of course, eventually do as you prefer")
that it was not necessary to see the things as in conflict. I am happy to
see that you think like me in this field, with a bit more certainties than
me (whenever self confidence is unwarranted, thence absolutism immediately
arises): my speech was open to be debated, yours is absolutist: you are the
holder of the Holy Graal of scripting, and you intervene as such -
GRATUITOUSLY.
document.images is not deprecated in XHTML yet name is? Who cares: in HTML 4
which is what our user uses they are not, and even if soemthing is
deprecated, yet it can be still used ESPECIALLY if the collection which uses
it is NOT deprectaed. I think you're not well aware of what you say. If the
collection is not deprectaed, ONE MORE reason to go on addressing it also by
name, not one less. And in fact - it works. Smoothly. Period.
Moreover, not deprectaing the collection yet deprecating the name which can
key the collection is highly contradictory - and we don't care a bit if it
is the w3c: deprecating the key of a collection but not the collection is a
deprecation that makes little sense: it is like keeping an array which can
be addressed by numerical key refusing to address it any longer by literal
names. And what's the logic in this move - but maybe you've been taught to
respect whatever is done by an authority regardless of the fact it needs not
to be always a terrific or a right move. Which doens't discredit the
authority actually, but reveals the limited level of ciritcal analysys that
you can attain (and sorry for misspellings, english is not my native tongue,
yet it should be clear).
otherwise you'd have to arrange it yourself, either patching up a collection by repeatedly calling in document.getElementById('image101') or by
document.getElementsByTagName("A")
the former is highly unpractical

What's highly unpractical when using, calling, resorting to an attribute
with a single, unique attribute value in a document?

I think you shoukld understand what you read before answering - you clearly
didn't.

The topic is: should we use a collection of all the images in a document?
Would such collection be useful?

The assumption is, yes OF COURSE it would ber useful - ya know those cases
when you want for instance apply via script something on all images.
Now, if the user in point refuses to resort to the name property or to
numerically indexed collections of images, and devotes him/herself
exclusively to id, this tantamount to the following: if he/she would one day
rebuild the whole collection in order to iterate it by the id of the images
(having given up the name), he/she'd have to do it calling in all the images
by id (imagine 20 images) and do:
-square brackets: that's an array in this case-

[document.getElementById("image1.jpg").id,
document.getElementById("image2.jpg") etc,
document.getElementById("image3.jpg"),
document.getElementById("image4.jpg"),
document.getElementById("image5.jpg"),
document.getElementById("image6.jpg"),
document.getElementById("image7.jpg"),
document.getElementById("image8.jpg"),
document.getElementById("image9.jpg"),
document.getElementById("image10.jpg"),
document.getElementById("image11.jpg"),
document.getElementById("image12.jpg"),
document.getElementById("image13.jpg"),
document.getElementById("image14.jpg"),
document.getElementById("image15.jpg"),
document.getElementById("image16.jpg"),
document.getElementById("image17.jpg"),
document.getElementById("image18.jpg"),
document.getElementById("image19.jpg"),
document.getElementById("image20.jpg")
]
In my house it is called unpractcal. So I'd rather sponsor:
for(var i in document.images){if(i!="length")alert(document.ima ges[i].src)}

Maybe you cannot see why one should iterate a collection by names instead
than by numerical index, but there are many things which you don't see here,
and by your attitude we could just give up all associative power in arrays
because you see that hey why not just using the numerical indexes and ids? I
think otherwise, I would never nevert give up associative power of the
collections because I know very well how much useful this associative power
can be when making interfaces with server side languages .- an example our
thread here "function EnablerInput() not working".
The facts are:
1- document.getElementsByName is slower and more memory demanding than
Excuse me, didn't I say that already?
let me see:
document.getElementsByTagName("A") //correct: IMG
"the second is much slower"

Yes, you speak of ByName - but I have personal reasons to suggest users EVEN
to never use byName (different from byTagName) anyway, regardless of its
speed or slowiness: on IE it grabs only forms and images - perhaps links but
if you give names to layers, it won't ghater the collection.

I mean, fantastic additions, yours: yet I don't understand why you gear them
addressing me. I could have understood "I want to add a few things to the
consideration made by others" and that would have been impersonal and fine -
yet this is not what you do, you're addressing me and contesting things
where there is nothing to contest. I truly don't understand what you're up
to - maybe bad mood who knows.
document.getElementById
2- document.getElementById is better supported by browsers, more
reliable, more recommendable and more relevant than
document.getElementsByName
I never quoted getElementsByName: i quoted getElementsByTagName, moreover
suggesting NOT to use it.
What is your point, and what the hack are you speaking of? Have you read my
post or you just got irritated by my website? - I found two of guys who did
in the last 3 years and out of that sense of annoynace they felt like they
had to blame me for something - who knows what...

, the second is much slower than just using

an object which is already within the built in arrays of a loaded

document.

And both are more slow than addressign directly the document.images
collection. So, what dio you want from me? I just don't get why you address
me with a set of fantastic allegations - that is a document.getElementByName
which I NEVER mentioned and with statements saying that such methods are
slower which is EXACTLY what I said. mah...
The issue was name versus id for <img>. The issue was not id versus
collection of tagname. The subject line for this thread was clear.
And so what? The user said: I will from now on use only the id. I stated
that if he doesn't use the name, he could eventually find that he would have
to wage slower methods to grab by name an object that can be easily
retrieved by the document.images collection though its name:
document.images["image1.jpg"] - certainly faster EVEN than getElementById,
but concerns of speed here acquire relevance ONLY if the user would ever
have to LOOP through the images addressing names/ids - which is what I was
highlighting. So what's your problem, my point falls perfectly within the
scope of the thread, what are you lecturing me about here? What gave to you
the impression in me that you can afford lecturing me and telling me that I
should not speak of names and ids and collections in this thread? About the
fact that if an user speak of id and name I cannot suggest in that thread
that he could use both? You're saying to me that's off topic? Wow.

Again, name for <img> (and for several other elements) is deprecated in
XHTML 1.

In HTML 4, name vs id for <a> is a different issue:
which can be the issue in point: it still falls within the scope of the
thread jimmy, FULLY. And guess what: I am ready to bet that the original
starter of the thread saves his own documents in plain html4 doctype - wanna
bet with me on that, jimmy?
"Use id or name? Authors should consider the following issues when
deciding whether to use id or name for an anchor name:
* The id attribute can act as more than just an anchor name (e.g.,
style sheet selector, processing identifier, etc.).
* Some older user agents don't support anchors created with the id
attribute.
* The name attribute allows richer anchor names (with entities)."

Good points, so what? why the hack you addressed me personally moreover
contesting things I never said and lecturing me on the topic of the thread?
mah, really we have to see weird stuff on newsgroups - you always find some
princess who has to make some very pinpointed specification on the actual
size of the 15th hair on the butt.

You always find guys who cannot just state their points in an objective way
without addressing any one: they have to invent pretexts to bolster their
evidently low self esteem dismissing soemone else first: they just cannot
make their points period, they have to wipe out and destroy first, and if
nothing can be attacked, well let's invent a way.

I speak of getElementsByTagName saying it is slow, he contests that
getElementsByName is slow.

I say it is unpractical arranging a collection by getElementById, he doens't
udnerstand one comma and asks what's unpractical with it. Making a brand new
id (the overtaker of name) addressable collection by it is what does is
unpractical indeed.

I answer to a third guy moreover adding expressions of relativism in my
points, he arrives with the 5th cavalry.

I asnwer in a thread about id and name speaking of name as used in a
collection, he lectures me on the topic of the thread. Some guys just
desperately search their personal bad word - and when they find it they're
capable of trading blame.

The moon suggests: understand what you read, and if you truly want to take
the INITIATIVE of personal attacks, be sure 1) you have arguments 2) you're
speaking of what was written and not of what you imagined 3) choose someone
at your level of knowledge - you know, I'm truly a javascript beginner ,
indeed, I know nothing of javascript, and I just should not speak of name
image properties in a thread dedicated to them: "Re: img name or ID"

Alberto
http://www.unitedscripters.com/

[Richard Cornford]

"Vicomte De Valmont" <NO****@hotmail.com> wrote in message
news:bn**********@lacerta.tiscalinet.it...
<snip>

Moreover, not deprectaing the collection yet deprecating the
name which can key the collection is highly contradictory -
and we don't care a bit if it is the w3c: deprecating the key
of a collection but not the collection is a deprecation that
makes little sense: it is like keeping an array which can be
addressed by numerical key refusing to address it any longer
by literal names. And what's the logic in this move - but maybe
you've been taught to respect whatever is done by an authority
regardless of the fact it needs not to be always a terrific or
a right move.

<snip>

In the W3C HTMLCollection interface specification we find:-

<quote>
Interface HTMLCollection
An HTMLCollection is a list of nodes. An individual node may
be accessed by either ordinal index or the node's name or id
attributes.
</quote>

-and the method namedItem with the definition:-

<quote>
namedItem
This method retrieves a Node using a name. With [HTML 4.01]
documents, it first searches for a Node with a matching id
attribute. If it doesn't find one, it then searches for a
Node with a matching name attribute, but only on those
elements that are allowed a name attribute. With
[XHTML 1.0] documents, this method only searches for Nodes
with a matching id attribute. This method is case insensitive
in HTML documents and case sensitive in XHTML documents.
Parameters
name of type DOMString
The name of the Node to be fetched.
Return Value
Node
The Node with a name or id attribute whose value corresponds
to the specified string. Upon failure (e.g., no node with
this name exists), returns null.
No Exceptions
</quote>

All DOM collections should implement the HTMLCollection interface and
JavaScript language bindings should mean that a property accessor syntax
using a property names (dot or square bracket notation) should be able
to reference a collection member by ID attribute (as namedItem should be
implemented as the "getter" for named properties).

So even with XHTML and no name attributes the various HTML DOM specified
collections should still be usable. At present older browsers may
implement collection objects that do not work with ID attributes, but
then, at present IE browsers have no idea what XHTML is so there is
questionable value in writing it in the first place.

Richard.

[Vicomte De Valmont]

That's VERY interesting, thank you a lot, very informative Richard! Of
course I was not saying that any illogical move had been _actually_ done, I
was only saying, replying to a strange unwarranted rebuttal-like post
accordingly to which we'd be wrong using both name and id properties in our
days, that _if_ what was reported namely that
--------quote
Name
attribute for <img> is deprecated in XHTML; accessing the collection
document.images is not deprecated in XHTML
--------unquote

if (if) that was the case and was true, _then_ it would have been somewhat
illogical to my eyes (deprecating a key to a collection which has not been
deprecated on its own turn, would have made very little sense indeed,
especially if you could then get the item by id only through
getElementById - we now see that the specification would allow addressing
the collections not only by number and name but *also* by id - and this is
remarkable and THIS makes sense). I am happy to see that things have not
been undertaken in the reported way. It made little sense and I should have
guessed that it was an incorrect or partial report. I just credited it, you
see, and elaborated on the credit that the assumption reflected the truth
(which would have been anyway a truth for the future not for the present: we
can count on a few fingers those who would choose nowadays to load a xhtml
document online instead than html - and I am a practical guy: browsers
should be taken for what they are and for what they actually do, not for
what they will be and what they should do :-)

ciao & thank you a lot again, very very informative - this is exactly the
activity that makes authentic sense - and falls in the scope of the thread
lol.
Alberto
http://www.unitedscripters.com/

"Richard Cornford" <Ri*****@litotes.demon.co.uk> ha scritto nel messaggio
news:bn*******************@news.demon.co.uk...

"Vicomte De Valmont" <NO****@hotmail.com> wrote in message
news:bn**********@lacerta.tiscalinet.it...
<snip>

Moreover, not deprectaing the collection yet deprecating the
name which can key the collection is highly contradictory -
and we don't care a bit if it is the w3c: deprecating the key
of a collection but not the collection is a deprecation that
makes little sense: it is like keeping an array which can be
addressed by numerical key refusing to address it any longer
by literal names. And what's the logic in this move - but maybe
you've been taught to respect whatever is done by an authority
regardless of the fact it needs not to be always a terrific or
a right move.

<snip>

In the W3C HTMLCollection interface specification we find:-

<quote>
Interface HTMLCollection
An HTMLCollection is a list of nodes. An individual node may
be accessed by either ordinal index or the node's name or id
attributes.
</quote>

-and the method namedItem with the definition:-

<quote>
namedItem
This method retrieves a Node using a name. With [HTML 4.01]
documents, it first searches for a Node with a matching id
attribute. If it doesn't find one, it then searches for a
Node with a matching name attribute, but only on those
elements that are allowed a name attribute. With
[XHTML 1.0] documents, this method only searches for Nodes
with a matching id attribute. This method is case insensitive
in HTML documents and case sensitive in XHTML documents.
Parameters
name of type DOMString
The name of the Node to be fetched.
Return Value
Node
The Node with a name or id attribute whose value corresponds
to the specified string. Upon failure (e.g., no node with
this name exists), returns null.
No Exceptions
</quote>

All DOM collections should implement the HTMLCollection interface and
JavaScript language bindings should mean that a property accessor syntax
using a property names (dot or square bracket notation) should be able
to reference a collection member by ID attribute (as namedItem should be
implemented as the "getter" for named properties).

So even with XHTML and no name attributes the various HTML DOM specified
collections should still be usable. At present older browsers may
implement collection objects that do not work with ID attributes, but
then, at present IE browsers have no idea what XHTML is so there is
questionable value in writing it in the first place.

Richard.