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 wrote:

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?
What you write in "meta" elements is more or less irrelevant (for XHTML
1.1). The important thing is what you're server is sending in the actual
HTTP header.

Here's a site where you can check what the browser and the server are
sending to each other behind your back:

<URL:http://webtools.mozill a.org/web-sniffer/>

Very useful!
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?
I do it with PHP. This function returns either "applicatio n/xhtml+xml"
or "text/html":

function ChooseMIME($a,$ u) {
if (substr_count($ u,'Netscape6') > 0 ) $ret = 'text/html';
if (!$ret) {
if (substr_count($ a,'application/xhtml+xml') == 0) {
$ret = 'text/html';
} else {
$xhtml_q = 1;
if
(preg_match("/application\/xhtml\+xml\s*;\ s*q\s*=\s*([\d\.]+)/",
$a,$m)) {
$xhtml_q = $m[1];
}
$html_q = 1;
if (preg_match("/text\/html\s*;\s*q\s* =\s*([\d\.]+)/",
$a,$m)) {
$html_q = $m[1];
}
if ($xhtml_q >= $html_q) $ret = 'application/xhtml+xml';
else $ret = 'text/html';
}
}
return $ret;
}

Call it like this:

$MIMEType = ChooseMIME(strt olower(getenv(' HTTP_ACCEPT')),
getenv('HTTP_US ER_AGENT'));

I make an exception for browsers calling themselves "Netscape 6".
Netscape 6 claims to be able to handle "applicatio n/xhtml+xml",
but actually it can't. Otherwise I go strictly by the Accept
header.
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?
If you want to use XHTML, but do not want to serve it as
"applicatio n/xhtml+xml", then you should use XHTML 1.0.

If you're only thinking about what is practical now, then you should
probably use HTML 4.01 Strict.
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).
Then use XHTML 1.0 Strict. It's 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.

I'm not sure about Google, but I do believe there are some serious
problems with Javascript and "applicatio n/xhtml+xml" in current
browsers.

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

[Haines Brown]

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

Then use XHTML 1.0 Strict. It's XML.

To revert from XHTML 1.1, I assume I'd just change:

<?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

to:

<?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN"
"http://www.w3.org/TR/xhtml11/DTD/strict.dtd">

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

[Bertilo Wennergren]

Haines Brown:

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

Then use XHTML 1.0 Strict. It's XML.

To revert from XHTML 1.1, I assume I'd just change: <?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> to: <?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN"
"http://www.w3.org/TR/xhtml11/DTD/strict.dtd"> Right?

Formally, yes (I can't think of anything else you'd need to change,
formally). But from a practical point of view (you want the page to work
in current browsers, I suppose), you'd also need to make sure you use
all the compatibility tricks noted here:

<URL:http://www.w3.org/TR/xhtml1/#guidelines>

If you want to serve an XHTML 1.0 page as "text/html" you should follow
those guidelines (writing e.g. "<br />" instead of "<br/>"). Some of
those tricks can be used in XHTML 1.1 as well without breaking any
rules, but some of them can't. So you'll have to do some converting, I'm
afraid.

Note that in "C.8. Fragment Identifiers" of those guidelines, the use of
both "id" and "name" is phrased with a weak "may be supplied", making it
(in my interpretation) not mandatory.

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

[Alan J. Flavell]

On Tue, Sep 9, Bertilo Wennergren inscribed on the eternal scroll:

Note that in "C.8. Fragment Identifiers" of those guidelines, the use of
both "id" and "name" is phrased with a weak "may be supplied", making it
(in my interpretation) not mandatory.

Appendix C is not normative anyway. You'd need to look elsewhere to
discern any mandatory requirements. The relevant part for XHTML/1.0
would be http://www.w3.org/TR/xhtml1/#h-4.10 which mandates the use of
id= and allows it (deprecated) to be shadowed by name=

Another relevant normative part would seem to be the HTML4 rules which
limit the syntax of these attributes, i.e
http://www.w3.org/TR/html4/types.html#h-6.2

cheers

[Bertilo Wennergren]

Alan J. Flavell:

On Tue, Sep 9, Bertilo Wennergren inscribed on the eternal scroll:

Note that in "C.8. Fragment Identifiers" of those guidelines, the use of
both "id" and "name" is phrased with a weak "may be supplied", making it
(in my interpretation) not mandatory.

Appendix C is not normative anyway.

Indeed. My use of "mandatory" should be taken in the context of wanting
and trying to conform to the text in "XHTML Media Types":

The use of 'text/html' for XHTML SHOULD be limited for the purpose of
rendering on existing HTML user agents, and SHOULD be limited to
[XHTML1] documents which follow the HTML Compatibility Guidelines.

<URL:http://www.w3.org/TR/xhtml-media-types/#media-types>

That document is just a "W3C Note". But many take its advice as a must,
and my comment was made supposing such a context.

If I author documents using only "id" for anchors, I can still claim
that I comply fully with the Compatibility Guidelines - in my meaning.
And I can then use "text/html" with XHTML 1.0, citing the W3C Note as
support.

Other parts of those Guidelines are worded more strongly. If you don't
follow those parts, you can hardly claim to be using those guidelines.

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

[Haines Brown]

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

To revert from XHTML 1.1, I assume I'd just change:

<?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

to:

<?xml version ="1.0" standalone="yes "?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN"
"http://www.w3.org/TR/xhtml11/DTD/strict.dtd">

I should not let this slip by. Although the answer was affirmative to
my question whether the above is correct, it turns out that the URL
was in error. The correct "preface" (as best I can make out--i.e., it
works) should be:

<?xml version ="1.0" standalone="yes " encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

(namespace reference here left out) I added the encoding above in
addition to defining it as follows:

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

because the W3C recommendations for XHTML 1.0 seemed to imply that
having it repeated in both places would reduce browser problems.

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

[Alan J. Flavell]

On Tue, Sep 9, Haines Brown inscribed on the eternal scroll:

(namespace reference here left out) I added the encoding above in
addition to defining it as follows:

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

because the W3C recommendations for XHTML 1.0 seemed to imply that
having it repeated in both places would reduce browser problems.

I wouldn't express it that way. The general W3C recommendation, as I
understand it, is the same as it was before: to specify the external
character encoding ("charset") on the HTTP header, where it belongs.

Appendix C (as now amended to take account of this general
recommendation) gives some advice for situations where, for some
reason, that isn't feasible. Then, it recommends defining the
"charset" on the <?xml-thingy (but that's a bad idea in practice, due
to a rather popular browser-like operating system component) for the
benefit of XML, -and- on a meta...charset thingy for compatibility
with HTML. Fair enough, as long as you understand what the parts are
for and why they are where they are. I was just a bit concerned at
the way you'd interpreted these bits of advice: providing the <?xml
thingy to IE, far from "avoiding browser problems", causes quirks mode
i.e re-creates "browser problems" even where there were none before.

all the best

[Jim Ley]

On Wed, 10 Sep 2003 02:14:24 +0200, "Alan J. Flavell"
<fl*****@mail.c ern.ch> wrote:

I was just a bit concerned at
the way you'd interpreted these bits of advice: providing the <?xml
thingy to IE, far from "avoiding browser problems", causes quirks mode
i.e re-creates "browser problems" even where there were none before.

I'd say if an author was so misguided as to give IE a XHTML doctype
when it's an HTML user agent, then the user is almost certainly
wanting quirks mode, since they're almost certainly not using XHTML
for appropriate reasons.

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

[Brian]

Jim Ley wrote:

to give IE a XHTML doctype when it's an HTML user agent

<span class="disdain" >sneeze</span>

..disdain:after {content: "bulls***" }

--
Brian
follow the directions in my address to email me

[Owen Jacobson]

Jim Ley wrote:

give IE a XHTML doctype when it's an HTML user agent

"Almost, but not entirely, totally unlike tea."