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.net> <http://www.bertilow.com>

[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.net> 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****@hartford-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.javascript 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
"application/xhtml+xml"). I serve XHTML 1.1 only to those browsers that
claim (in the Accept header) to be able to handle
"application/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.net> <http://www.bertilow.com>

[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.net> 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
"application/xhtml+xml").
I tested this by replacing "text/html" above with
"application/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 "application/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****@hartford-hwp.com> writes:

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

I tested this by replacing "text/html" above with
"application/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****@hartford-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
"application/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 "application/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.javascript 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.

[Bertilo Wennergren]

Haines Brown wrote:

Bertilo Wennergren <be******@gmx.net> 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
"application/xhtml+xml"). I tested this by replacing "text/html" above with
"application/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.mozilla.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 "application/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 "application/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(strtolower(getenv('HTTP_ACCEPT')),
getenv('HTTP_USER_AGENT'));

I make an exception for browsers calling themselves "Netscape 6".
Netscape 6 claims to be able to handle "application/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
"application/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 "application/xhtml+xml" in current
browsers.

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

[Haines Brown]

Bertilo Wennergren <be******@gmx.net> 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.net> 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.net> <http://www.bertilow.com>

[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.net> <http://www.bertilow.com>

[Haines Brown]

Haines Brown <br****@hartford-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.cern.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.javascript 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."

[Alan J. Flavell]

On Wed, Sep 10, Jim Ley inscribed on the eternal scroll:

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.

I suppose statistically you might very well be right: the proportion
of us who have been trying to use HTML in accordance with published
specifications has been relatively small. But just wait: the
supporters of Sturgeons Law are already propagating their quasi-XHTML
tag soup - soon there will be no hiding from it there either.

[Jim Ley]

On Wed, 10 Sep 2003 15:02:12 GMT, Haines Brown
<br****@hartford-hwp.com> wrote:

Then Jim L. appears to suggest thay by identifying a doctype as XHTML,
the IE "HTML user agent" will naturally be quirky. Does this mean
simply that IE does not handle XHTML docs reliably?
IE makes no claims to support XHTML, it renders XHTML as if it was
HTML tag-soup, you're getting lucky with its tag-soup parser. In fact
all the major browsers when they get XHTML served as text/html are
treating it as tag-soup, so you're just getting lucky.
1. XHTML is a threat to reliable browser performance, and so one
should use HTML unless there's good reason not to.
Yes, if the XHTML is served as text/html, not if XHTML is served as
application/xhtml+xml
2. If one uses XHTML, the char set specification should appear only in
the content-type meta statement and not in the document preface
(material before the <head> container). To have it in both places
might cause IE misbehavior.
No, it should only appear in the mime-type text/html; charset=x-foo
3. IE unreliability is likely to increase because MS is unable or
unwilling to improve it in order to display XML documents reliably.

IE is not an XHTML user agent, IE has no reason to become an XHTML
user agent until people start serving XHTML documents, if you tell it
you've got an HTML doc, and then give it some tag-soup, don't be
surprised that it doesn't do exactly what you expect.

text/html is not an XML mime-type, so it should not be doing XML
things with it - serve it as application/xml and IE will do an
appropriate thing with your document.

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

[Alan J. Flavell]

On Wed, Sep 10, Jim Ley inscribed on the eternal scroll:

On Wed, 10 Sep 2003 15:02:12 GMT, Haines Brown
<br****@hartford-hwp.com> wrote:

2. If one uses XHTML, the char set specification should appear only in
the content-type meta statement and not in the document preface
(material before the <head> container). To have it in both places
might cause IE misbehavior.
No, it should only appear in the mime-type text/html; charset=x-foo

The questioner might need to be told explicitly that this is part
of the HTTP transaction response header, per RFC2616, and has nothing
at all to do with the HTML <head> container which, as far as HTTP is
concerned, is part of the "response body".

See e.g
http://www.w3.org/Protocols/rfc2616/....html#sec14.17
IE is not an XHTML user agent, IE has no reason to become an XHTML
user agent until people start serving XHTML documents, if you tell it
you've got an HTML doc, and then give it some tag-soup, don't be
surprised that it doesn't do exactly what you expect.

I've learned not to expect it to conform with published interworking
requirements either, so if I ever send it properly-conforming HTML and
it does the right thing then it's a pleasant surprise...

But I agree with your bottom-line conclusion: sending out conforming
HTML currently offers the best chance of success, and as the only
other "compatible-in-practical-terms" option on offer is Appendix C
XHTML/1.0, which is functionally identical to HTML/4.01 just with
XML-ised syntax, then HTML/4.01 seems the practical choice for
real-world deployment. By all means choose (or migrate towards) the
"Strict" variant, using CSS to propose the presentation - this is a
good move irrespective of the choice between HTML and XHTML.

And what you do on the lab bench is something else entirely, but
probably not ready for real-world deployment except with a known
specialist audience who has a specific need for the features (be they
MathML, SVG or whatever) and resulting willingness to acquire whatever
it takes to view them.

cheers