Name attribute for anchor doesn't validate

[Haines Brown]

I have a document with a set of internal links such as:

<a name="Z1"></a>...
<a name="Z2"></a>...

The W3C validator objects to the first instance of the name attribute:
There is no attribute "FOO" for this element (in this HTML
version). The element is defined not to have this attribute.

These anchors are not contained in anything. For example, the Z1
anchor context is actually:

...
</ul>
<hr />
<a name="Z1"></a>
<h2>Title</h2>
<dl>
...

The error is triggered only by the first instance of the name
attribute, and so not by anchors Z2, Z3, ...

My doctype is xhtml11, and my browser is galeon. In my stylesheet,
the a element is defined only with regard to its pseudo-elements.

If I change the first statement to:

<a id="Z1"></a>...

Then the error is triggered by the Z2 anchor, etc.

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

[Bertilo Wennergren]

Haines Brown:

I have a document with a set of internal links such as: <a name="Z1"></a>...
<a name="Z2"></a>...

The W3C validator objects to the first instance of the name attribute:
There is no attribute "FOO" for this element (in this HTML
version). The element is defined not to have this attribute.
That's true. So remove the "name" attribute.
My doctype is xhtml11, and my browser is galeon. In my stylesheet,
the a element is defined only with regard to its pseudo-elements. If I change the first statement to:

<a id="Z1"></a>... Then the error is triggered by the Z2 anchor, etc.

Change all of them to "id". There is no "name" attribute for "a"
elements in XHTML 1.1.

--
Bertilo Wennergren <be******@gmx.n et> <http://www.bertilow.co m>

[David Dorward]

Haines Brown wrote:

I have a document with a set of internal links such as:

<a name="Z1"></a>...
<a name="Z2"></a>...
Oooh, old style.
The W3C validator objects to the first instance of the name attribute:
There is no attribute "FOO" for this element (in this HTML
version). The element is defined not to have this attribute.
The name attribute for anchors was removed in XHTML 1.1
These anchors are not contained in anything.
That's irrelevent.
The error is triggered only by the first instance of the name
attribute, and so not by anchors Z2, Z3, ...
That's for clarity. Duplicate errors are not displayed. (Depending on the
circumstances)
My doctype is xhtml11, and my browser is galeon.
The browser is irrelevent when discussing validation.
In my stylesheet, the a element is defined only with regard to its
pseudo-elements.
Still irrelevent.
If I change the first statement to:

<a id="Z1"></a>...

Then the error is triggered by the Z2 anchor, etc.

Of course, its still an error.

You probably want: <h2 id="Z1">Title</h2>

Netscape 4 and other anchient browsers won't support it, if you care about
them go back to XHTML 1.0... or HTML 4.01.

--
David Dorward http://dorward.me.uk/

[Haines Brown]

Bertilo Wennergren <be******@gmx.n et> writes:

Haines Brown:

I have a document with a set of internal links such as:

<a name="Z1"></a>...
<a name="Z2"></a>...
The W3C validator objects to the first instance of the name
attribute:
There is no attribute "FOO" for this element (in this HTML
version). The element is defined not to have this attribute.

That's true. So remove the "name" attribute.

Bertilo. Interesting. I see the error of my ways. I use as a
reference, Ian Graham's XHTML 1.0, and apparently the name attribute
was OK in XHTML 1.0, and even preferred because supported by older
browsers.

I infer that in XHTML 1.1, the name attribute is no longer valid and
should not be used, even though some older browsers will no longer
understand fractional links.

So, what would you recommend as a good hard copy reference for XHTML
_1.1_?

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

[Jim Ley]

On Sun, 07 Sep 2003 23:43:50 GMT, Haines Brown
<br****@hartfor d-hwp.com> wrote:

I infer that in XHTML 1.1, the name attribute is no longer valid and
should not be used, even though some older browsers will no longer
understand fractional links.
You should not be serving XHTML 1.1 to any old browsers, it is not
allowed to have a text/html mime-type, so they will not be served it
by your server (and if they will they won't know what to do with it)
So, what would you recommend as a good hard copy reference for XHTML
_1.1_?

I wouldn't bother with it, it's highly unlikely enough UA's will come
along to make it worthwhile, wait until XHTML 2.0 or some other rich
semantic html successor comes along.

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

[Bertilo Wennergren]

Haines Brown:

I see the error of my ways. I use as a
reference, Ian Graham's XHTML 1.0, and apparently the name attribute
was OK in XHTML 1.0, and even preferred because supported by older
browsers.
It was kept temporarily to make backwards compatible authoring possible
(compatible with old browsers).
I infer that in XHTML 1.1, the name attribute is no longer valid and
should not be used, even though some older browsers will no longer
understand fractional links.
There are very few of them left. I stopped using "name" for anchors a
few months ago. No one has complained yet.
So, what would you recommend as a good hard copy reference for XHTML
_1.1_?

Good question. I don't think there is any good reference that presents
_all_ such changes in XHTML 1.1. I found some of the out only when I
validated my pages. (One surprising difference is that "body" can not be
empty anymore! Make such a page. Mark it as XHTML 1.0 and validate. Then
change to XHTML 1.1 and validate again.)

You should know that only a very small minority of users will be able to
see your XHTML 1.1 pages if you serve them correctly (as
"applicatio n/xhtml+xml"). I serve XHTML 1.1 only to those browsers that
claim (in the Accept header) to be able to handle
"applicatio n/xhtml+xml". The others get XHTML 1.0 served as "text/html".
From a practical point of view I could just as well serve them all
XHTML 1.0 as "text/html", but I like being on the bleeding edge. If you
don't have any special reason to use XHTML (1.0 or 1.1), you will
probably be better off using HTML 4.01 Strict.

--
Bertilo Wennergren <be******@gmx.n et> <http://www.bertilow.co m>

[Haines Brown]

I have _not_ set my XHTML pages up correctly according to W3C
suggestions, for I presently have:

<?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
...
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

That is, I here define the document as XHTML 1, but its Internet MIME
type as text/html. According to W3C, one "should" _not_ use an
Internet document type definition "text/html" for XHTML
documents. However, the reasons seemed unimportant for me (access to
other namespaces; definition of character set). That is, I assumed I
could get away with it. Was my reasoning incorrect?

Bertilo Wennergren <be******@gmx.n et> writes:

You should know that only a very small minority of users will be
able to see your XHTML 1.1 pages if you serve them correctly (as
"applicatio n/xhtml+xml").
I tested this by replacing "text/html" above with
"applicatio n/xhtml+xml" on a test page rendered by an old IE. It seemed
to render OK. Your remark suggests that it shouldn't have displayed
properly. What am I missing here?
I serve XHTML 1.1 only to those browsers that claim (in the Accept
header) to be able to handle "applicatio n/xhtml+xml". The others get
XHTML 1.0 served as "text/html".
Nice, but could I ask how you do this explicitly?
From a practical point of view I could just as well serve them all
XHTML 1.0 as "text/html", but I like being on the bleeding edge. If
you don't have any special reason to use XHTML (1.0 or 1.1), you will
probably be better off using HTML 4.01 Strict.

Are you saying that my current definition above is a "practical"
solution although not meeting W3C suggestions? Is there any reason
then that I should not continue as I have?

I find myself on what you call the "bleeding edge" for a different
reason, which is that I generate a lot of docs that I hope will find
future use, but I'll never be able to update. That is, I want the
documents to be as flexible as possible (ie., XML). The Internet MIME
type seems a secondary issue, but I remain uncertain whether the
text/html type is wrong in principle but works in practice, and
whether application/xhtml+xml is right in principle, but useless in
practice.

I've heard that application/xhtml+xml kills javascript and defeats
google, and so people retreat to text/html.

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

[Chris Morris]

Haines Brown <br****@hartfor d-hwp.com> writes:

<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

I tested this by replacing "text/html" above with
"applicatio n/xhtml+xml" on a test page rendered by an old IE. It seemed
to render OK. Your remark suggests that it shouldn't have displayed
properly. What am I missing here?

Mime types specified by <meta http-equiv> get ignored more often. Set
it in the actual headers using .htaccess (if an Apache server) or some
server-side processing.

--
Chris

[Jim Ley]

On Mon, 08 Sep 2003 13:42:32 GMT, Haines Brown
<br****@hartfor d-hwp.com> wrote:

<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
This isn't where you set the mime-type...
However, the reasons seemed unimportant for me (access to
other namespaces; definition of character set).
You don't get XML rules of character sets if you serve it as
text/html, so that's irrelevant. You should not use multiple
namespaces if you serve it as text/html, they're ignored anyway by all
the tools that process it as text/html - so how can you need them?
I tested this by replacing "text/html" above with
"applicatio n/xhtml+xml" on a test page rendered by an old IE. It seemed
to render OK. Your remark suggests that it shouldn't have displayed
properly. What am I missing here?
You didn't change the mime-type, if you had IE would not have
attempted to render it, you can make IE render it (by telling it the
mime-type of html is application/xhtml+xml) but then it gets a fair
bit wrong, still treats it as tag-soup and breaks text/html pages!

The mime-type is sent in the HTTP headers, not in the document.

I serve XHTML 1.1 only to those browsers that claim (in the Accept
header) to be able to handle "applicatio n/xhtml+xml". The others get
XHTML 1.0 served as "text/html".

Nice, but could I ask how you do this explicitly?

Not really, you should serve XHTML 1.0 as application/xhtml+xml, and I
don't see the point in violating shoulds without good reason, serving
XHTML 1.0 is not a good reason, HTML 4.01 is the same.
I find myself on what you call the "bleeding edge" for a different
reason, which is that I generate a lot of docs that I hope will find
future use, but I'll never be able to update.
HTML 4.01strict served as text/html is certainly your best approach
then, application/xhtml+xml is so rarely used I can certainly forsee
XHTML 2.0 only user-agents existing not caring a jot about the tiny
minority of XHTML 1.* docs around. HTML 4.01 support will be more
likely to continue, and if it doesn't then there's more likelyhood it
will be converted to some other format later in the day. HTML 4.01 ->
XHTML apache modules exist today for example, and there's a huge
legacy HTML rump of data that will need the treatment.
I've heard that application/xhtml+xml kills javascript and defeats
google, and so people retreat to text/html.

Yes, people have all sorts of good justifications for violating
recommendations , but the more they abuse it, the worse the situations
get.

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

[Alan J. Flavell]

On Mon, Sep 8, Chris Morris inscribed on the eternal scroll:

Mime types specified by <meta http-equiv> get ignored more often.
I should certainly hope so: RFC2616 mandates that the HTTP-supplied
value is authoritative.

[Sure, IE rules itself out as a WWW browser (not only) on this
requirement; but in the present context it makes no difference, since
IE dreams-up its bogus information from quite different sources.

And note that trying to mess with "charset" via meta http-equiv comes
too late for XML. In this case it didn't matter, since the meta was
only confirming what XML would have already decided anyway.
Set it in the actual headers using .htaccess (if an Apache server)
or some server-side processing.

Indeed.