Empty a valid or not?

[Neal]

According to the specs
(http://www.w3.org/TR/html401/struct/links.html#h-12.2), the <a> element
requires an end tag. And so, when we use <A NAME="foo"> in HTML 2.0 to
4.01, it won't validate, it'll want to find the </A> tag.

However, when I write a document containing, say, <a name="foo" /> it
validates in XHTML 1.0.

I'm obviously missing something here, as this confuses me somewhat. Does
the magical / make the empty a element valid? And doesn't this violate
http://www.w3.org/TR/xhtml1/#C_3 ?

Nearest I can figure, it's recommending that although the tag will
validate, we still shouldn't do it in case a UA can't handle an empty a
element. Am I on the right track?

If not, feel free to correct me.

[Spartanicus]

Neal <ne*****@spamrcn.com> wrote:

According to the specs
(http://www.w3.org/TR/html401/struct/links.html#h-12.2), the <a> element
requires an end tag. And so, when we use <A NAME="foo"> in HTML 2.0 to
4.01, it won't validate, it'll want to find the </A> tag.

However, when I write a document containing, say, <a name="foo" /> it
validates in XHTML 1.0.

I'm obviously missing something here, as this confuses me somewhat. Does
the magical / make the empty a element valid? And doesn't this violate
http://www.w3.org/TR/xhtml1/#C_3 ?

Nearest I can figure, it's recommending that although the tag will
validate, we still shouldn't do it in case a UA can't handle an empty a
element. Am I on the right track?

Consider dropping the silly construct completely:

<h3 id="s5">Section 5</h3>

--
Spartanicus

[Bertilo Wennergren]

Neal:

According to the specs
(http://www.w3.org/TR/html401/struct/links.html#h-12.2), the <a> element
requires an end tag. And so, when we use <A NAME="foo"> in HTML 2.0 to
4.01, it won't validate, it'll want to find the </A> tag. However, when I write a document containing, say, <a name="foo" /> it
validates in XHTML 1.0.

In HTML 2.0 to 4.01 you must write "<a ...>...</a>".

In XHTML you can also write "<a ... />".

The rules are different. In XHTML such an added "/" at the end of a
start tag closes the element. That is unknown in older HTML.

Writing "<a ... />" might however not work well in old user agents that
don't know anything about XHTML.

Do look up the specification for XHTML 1.0.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Jukka K. Korpela]

Spartanicus <[e-mail]> wrote:

Consider dropping the silly construct completely:

<h3 id="s5">Section 5</h3>

It's not silly if you need or wish to have your document working on
Netscape 4 too. The poor browser does not jump to anchors defined by id
attributes, it needs <a name>. Personally I'm moving to id attributes
in new documents, mostly, but with some hesitation.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Bertilo Wennergren]

Jukka K. Korpela:

Spartanicus <[e-mail]> wrote:

Consider dropping the silly construct completely: <h3 id="s5">Section 5</h3>

It's not silly if you need or wish to have your document working on
Netscape 4 too. The poor browser does not jump to anchors defined by id
attributes, it needs <a name>. Personally I'm moving to id attributes
in new documents, mostly, but with some hesitation.

I hesitated too, but finally I moved to "id"s on all of my pages.
I haven't had one single complaint.

I guess it all depends on how important your anchors are, and on how
many of your visitors use Netscape 4.

(Netscape 4 users are probably quite accustomed to things not working
very well by now... Maybe they like pain...)

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

Consider dropping the silly construct completely:

<h3 id="s5">Section 5</h3>
It's not silly if you need or wish to have your document working on
Netscape 4 too.

That doesn't make the *construct* less silly.
The poor browser does not jump to anchors defined by id
attributes, it needs <a name>.

I know, and don't care.

--
Spartanicus

[CJM]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn*****************************@193.229.0.31. ..

It's not silly if you need or wish to have your document working on
Netscape 4 too. The poor browser does not jump to anchors defined by id
attributes, it needs <a name>. Personally I'm moving to id attributes
in new documents, mostly, but with some hesitation.

I tend to use both name & ID; it seems a bit inefficient but different
things need each of them.

In addition to NS4, I need the NAME attribute for ASP forms...

But my Javascript validation code needs the ID...

Chris

[Harlan Messinger]

"Neal" <ne*****@spamrcn.com> wrote in message
news:op**************@news.rcn.com...

According to the specs
(http://www.w3.org/TR/html401/struct/links.html#h-12.2), the <a> element
requires an end tag. And so, when we use <A NAME="foo"> in HTML 2.0 to
4.01, it won't validate, it'll want to find the </A> tag.

However, when I write a document containing, say, <a name="foo" /> it
validates in XHTML 1.0.

I'm obviously missing something here, as this confuses me somewhat. Does
the magical / make the empty a element valid? HTML is HTML and XHTML is XHTML. Each has its own rules, and even though
they have much in common, you can't determine the correctness of an
expression in XHTML document by the rules of HTML.

Also, don't confuse an empty element with the omission of the closing tag.
In HTML,

<p>Paragraph 1<p>Paragraph 2</p>

has two P elements, neither of which is empty, but the closing tag for the
first is missing. On the other hand, while you have to have a closing tag
for an A element, as you noted, an empty A is perfectly valid:

<a name="foo"></a>

Finally, in XHTML, <tag /> means <tag></tag>. In the case of <a name="foo"
/>, the slash isn't making anything valid. In XHTML as in HTML, an empty A
element is valid, whether written as <a name="foo" /> or as <a
name="foo"></a>.
And doesn't this violate http://www.w3.org/TR/xhtml1/#C_3 ?

Nearest I can figure, it's recommending that although the tag will
validate, we still shouldn't do it in case a UA can't handle an empty a
element. Am I on the right track?

It's not directly about whether a non-XHTML UA can handle an empty element,
but about how it will treat the lack of an explicit closing tag.

1. It's fine to use <tag /> for elements that, in HTML, have no closing tag,
either required or optional. (These are *by definition* empty, but the
emptiness is not directly the issue here.)

For example, if an HTML-only UA reads <input ... />, it will treat it as
<input ...>, which doesn't *have* a closing tag in HTML, so the UA won't
think anything is unusual, and will process the tag correctly.

2. The <tag /> form won't validate for elements that, in HTML, have a
mandatory closing tag.

For example, if an HTML-only UA reads <a name="foo" />, it will treat it as
<a name="foo"> but it won't find a closing tag, which will be an error that
the UA will handle however it normally handles that situation.

3. The result of <tag /> may not be the one intended, in the case of
elements that, in HTML, have an optional closing tag.

For example, if an HTML-only UA reads <p />, it will treat it as <p>, and
will then follow the usual rules for assuming an implicit </p> just before
the start of the next element that can't be nested inside a P element. So

<p />Foo<p>Bar</p>

will be treated as

<p>Foo</p><p>Bar</p>

and not as

<p></p>Foo<p>Bar</p>

[kaeli]

In article <bu************@ID-209813.news.uni-berlin.de>,
cj*****@yahoo.co.uk enlightened us with...

I tend to use both name & ID; it seems a bit inefficient but different
things need each of them.

In addition to NS4, I need the NAME attribute for ASP forms...

But my Javascript validation code needs the ID...

Yup, same here.
I use both, and for the same reasons.

Also, on occasion I have need of document.getElementsByName and arrays
of elements with the same name. Ids are supposed to be unique, so you
can't have a bunch of radio buttons, checkboxes, etc with the same id.
But they have to have the same name or they won't work right (radio
buttons, anyway).
Sometimes I want checkboxes instead od radio buttons because I want the
user to be able to choose multiples, but I want them with the same name
because they are really the same thing and get stored together server-
side.

--
--
~kaeli~
Suicide is the most sincere form of self-criticism.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Jim Ley]

On Wed, 14 Jan 2004 12:05:50 +0100, Bertilo Wennergren
<be******@gmx.net> wrote:

Do look up the specification for XHTML 1.0.

But please ignore appendix C - or do all of it, including the bits
that require you to use XML PI's for stylesheets and also ensure you
avoid XML PI's.

The result being of course you can't use stylesheets, but that's not
too bad is it?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Stan Brown]

It seems "Bertilo Wennergren" wrote in
comp.infosystems.www.authoring.html in article
<bu*************@news.t-online.com>:

I hesitated too, but finally I moved to "id"s on all of my pages.
I haven't had one single complaint.

It's not likely you would.

Very few Web surfers take the trouble to report broken links, even
ones that give "page not found". Since this type of broken link at
least lands on the right page, it's that much less likely to prompt
someone to report the problem.

Luckily only Netscape 4 is affected by this.

I still do <a name=...> because my script that generates tables of
contents expects <h2><a name="...">...</a></h2> and I haven't got
round to changing it to expect <h2 id="...">...</h2>. :-)

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Stan Brown]

It seems "Spartanicus" wrote in comp.infosystems.www.authoring.html
in article
<ld********************************@news.spartanic us.utvinternet.ie>

Consider dropping the silly construct completely:
<h3 id="s5">Section 5</h3>

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

It's not silly if you need or wish to have your document working on
Netscape 4 too.

The poor browser does not jump to anchors defined by id
attributes, it needs <a name>.

I know, and don't care.

As Church Lady would say, "Well, isn't that _special_!"

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Neal]

On Wed, 14 Jan 2004 09:44:47 +0000, Spartanicus <[e-mail]> wrote:

Consider dropping the silly construct completely:

<h3 id="s5">Section 5</h3>

I'd like to. Believe me. But older browsers cannot find ids from a link.
Gotta use a name for backward compatability, and in my situation, that's a
must.

[Neal]

On Wed, 14 Jan 2004 16:26:02 -0500, Stan Brown
<th************@fastmail.fm> wrote:

Very few Web surfers take the trouble to report broken links, even
ones that give "page not found". Since this type of broken link at
least lands on the right page, it's that much less likely to prompt
someone to report the problem.

Luckily only Netscape 4 is affected by this.

Problem is, the main reason I use this type of link is to allow users of
said Netscape to get from the top to the bottom, as they cannot view the
layout I've designed for more modern browsers. So normally the link is to
the same page they are on, and therefore does nothing if it references a
value that is an id and not a name.

For this situation, the only workaround is to continue the practice of
using a names until the old Netscape browsers have gone the way of the
dodo.

[Keith Bowes]

Neal wrote:

Problem is, the main reason I use this type of link is to allow users of
said Netscape to get from the top to the bottom, as they cannot view the
layout I've designed for more modern browsers. So normally the link is
to the same page they are on, and therefore does nothing if it
references a value that is an id and not a name.

For this situation, the only workaround is to continue the practice of
using a names until the old Netscape browsers have gone the way of the
dodo.

Unless your site has an unusually high concentration of NS4 users, it is
extinct. Browsers never really became extinct; they just fall into the
realm of being rarely used.

But since you have that great layout, can't you just arrange it so that
the content is first in NS4 and make it appear otherwise in newer browsers?

[Jim Dabell]

Jim Ley wrote:

On Wed, 14 Jan 2004 12:05:50 +0100, Bertilo Wennergren
<be******@gmx.net> wrote:

Do look up the specification for XHTML 1.0.

But please ignore appendix C - or do all of it, including the bits
that require you to use XML PI's for stylesheets and also ensure you
avoid XML PI's.

The result being of course you can't use stylesheets, but that's not
too bad is it?

I don't see anything that prohibits use of the <link> element to reference
external stylesheets. I _do_ see C.14 that requires use of a PI for
<style> elements, but it's usually better to use external stylesheets
anyway.
--
Jim Dabell

[Neal]

On Wed, 14 Jan 2004 16:52:30 +0000, Keith Bowes <do****@spam.me> wrote:

But since you have that great layout, can't you just arrange it so that
the content is first in NS4 and make it appear otherwise in newer
browsers?

Content is first. Purpose of links is to direct users to navigation, and
back to content from bottom of page. As some pages have multiple columns
of layout, this is a nice gesture, though certainly I could neglect them.

The target audience of this site works out to be, largely, people with
lesser computer skills and often old equipment - definitely not a
tech-savvy population. I've not done any sort of study, but I think it's
safe to assume the proportion of older browsers visiting this site is
higher than average. Plus it's for a non-profit, so we really don't want
to piss anybody off.

[Bertilo Wennergren]

Stan Brown:

It seems "Bertilo Wennergren" wrote:

I hesitated too, but finally I moved to "id"s on all of my pages.
I haven't had one single complaint.

It's not likely you would. Very few Web surfers take the trouble to report broken links, even
ones that give "page not found". Since this type of broken link at
least lands on the right page, it's that much less likely to prompt
someone to report the problem.

Still I have a somewhat special audience, and many of my pages have
unique content with no alternative anywhere else. So I would actually
expect to get at least some complaints.

And I do get complaints about other things on my pages.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Nick Kew]

In article <op**************@news.rcn.com>, one of infinite monkeys
at the keyboard of Neal <ne*****@spamrcn.com> wrote:

According to the specs
(http://www.w3.org/TR/html401/struct/links.html#h-12.2), the <a> element
requires an end tag. And so, when we use <A NAME="foo"> in HTML 2.0 to
4.01, it won't validate, it'll want to find the </A> tag.
Correct.
However, when I write a document containing, say, <a name="foo" /> it
validates in XHTML 1.0.
Correct. You've invoked an XML shorthand.
I'm obviously missing something here, as this confuses me somewhat. Does
the magical / make the empty a element valid? And doesn't this violate
http://www.w3.org/TR/xhtml1/#C_3 ?
Yes, it does violate Appendix C. But apart from being internally
inconsistent, Appendix C is in any case not normative, so violating
it isn't technically an error.
Nearest I can figure, it's recommending that although the tag will
validate, we still shouldn't do it in case a UA can't handle an empty a
element. Am I on the right track?
Yes, that's the purpose of Appendix C. But using XHTML makes life more
difficult for you, because it means validation will not spot the problem.

If you have a system that's generating empty <a>s and such things,
you can fix them by post-processing the output. See
http://apache.webthing.com/mod_xmlns/
for an Apache-based solution.
If not, feel free to correct me.

Congratulations on arriving at one of the fundamental problems with
the "thinking" behind XHTML.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html