img name or ID

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

"DU" <drunclear (AT) hot-R-E-M-O-V-E-mail (DOT) com> wrote

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.

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.

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" <no (AT) spam (DOT) com> ha scritto nel messaggio
newsJWdnUQbLMEcBgGiRVn-jw (AT) giganews (DOT) com...

"DU" <drunclear (AT) hot-R-E-M-O-V-E-mail (DOT) com> wrote in message
news:bni5pn$no6$1 (AT) news (DOT) 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.

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])."

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/groups?as_u...) 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

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/groups?as_u...) 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

JRS: In article <20031026154742.28070.00000204 (AT) mb-m27 (DOT) aol.com>, seen in
news:comp.lang.javascript, HikksNotAtHome <hikksnotathome (AT) aol (DOT) com>
posted at Sun, 26 Oct 2003 20:47:42 :-

From: "TheKeith" no (AT) spam (DOT) 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.

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 / ??.Stockton (AT) physics (DOT) 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)

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

"DU" <drunclear (AT) hot-R-E-M-O-V-E-mail (DOT) 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/