XHTML namespace declararion: needed or not?

D

David Higgins

I am confused about strictly conforming XHTML1.1 documents. We know
that putting anything before the DOCTYPE declaration causes IE to go
into quirks mode, so I leave out <?xml version="1.0"
encoding="UTF-8"?>, and the w3c validator is fine with that. Then the
DOCTYPE declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Then the namespace designator in the html tag:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >

I think I understand what the DOCTYPE is all about, but what is the
namespace designator for (as advised in
http://www.w3.org/TR/xhtml11/conformance.html#s_conform )?

Leaving out the namespace designation also does not cause an error on
the w3c validator.

Two questions:
(1) what effect, if any, is there of leaving out <?xml version="1.0"
encoding="UTF-8"?> ?
(2) what effect, if any, is there of leaving out
xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" ?

Thanks for any info
Dave Higgins
 
T

Toby A Inkster

David said:
I think I understand what the DOCTYPE is all about, but what is the
namespace designator for?
Click to expand...

XHTML is a flavour of XML. But there are various other flavours of XML
too, like WML (used to provide web pages on mobile devices, and supported
by Opera 7).

Namespaces are how the browser differentiates between the <head> element
of XHTML and the <head> element of WML (and other XML languages)
 
D

David Dorward

I have never had this issue. It seems to me this would only be a
problem if you served the document with a Content-Type of
text/xml (or similar) instead of text/html.
Click to expand...

Ah. You mean if you do what you are SUPPOSED to do?
 
M

Micah Cowan

I am confused about strictly conforming XHTML1.1 documents. We know
that putting anything before the DOCTYPE declaration causes IE to go
into quirks mode, so I leave out <?xml version="1.0"
encoding="UTF-8"?>, and the w3c validator is fine with that. Then the
DOCTYPE declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Then the namespace designator in the html tag:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >

I think I understand what the DOCTYPE is all about, but what is the
namespace designator for (as advised in
http://www.w3.org/TR/xhtml11/conformance.html#s_conform )?

Leaving out the namespace designation also does not cause an error on
the w3c validator.

Two questions:
(1) what effect, if any, is there of leaving out <?xml version="1.0"
encoding="UTF-8"?> ?
Click to expand...

The possibility of confusing a processing application whether it
is SGML or XML. This is very unlikely to give you any problems:
it simply serves to identify the document as XML. But also it
identifies the encoding being used: make sure that you have the
Content-Type HTTP header or <meta/> equivalent so it will be
interpreted correctly. IIRC, older IEs tend to assume
ISO-8859-1, whereas newer ones assume UTF-8.
(2) what effect, if any, is there of leaving out
xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" ?
Click to expand...

Not much. As to the xmlns attribute: it has that value whether or
not you explicitly specify it. It is mainly useful for when the
DOCTYPE is not html, but something else which has XHTML embedded
within it. As to xml:lang, it could affect some small details in
how your document is handled; but any processing application with
knowledge of HTML will look at your html lang attribute anyway,
so I doubt there'd be a problem.

....however, what's the point in removing these? Browsers will
ignore any attributes they don't understand, so leaving them
(which I recommend) in can't possibly hurt.

HTH,
Micah
 
M

Micah Cowan

David Dorward said:
http://dorward.me.uk/tmp/xhtml/xhtml-with-no-namespace.xhtml

Mozilla fails to recognise it as XHTML and treats it like any other XML
document.
Click to expand...

I have never had this issue. It seems to me this would only be a
problem if you served the document with a Content-Type of
text/xml (or similar) instead of text/html. I'm not sure why you
would do this, since many other browsers would fail to interpret
it at all on anything other than text/html.

Or, maybe you meant it treats it like any other *HTML* document,
which would make more sense given the URL you specified
above. This has never been a problem for me, since I make a point
to create XHTML documents which will be correctly interpreted by
most non-XHTML-aware user agents.

-Micah
 
E

Eric B. Bednarz

David Dorward said:
Micah Cowan wrote:
Click to expand...

[It's... the namespaces; if you don't have a life anyway, start your
next spare weekend ahead with:

If you're not using XHTML, that's not surprising, is it?

Some of the numerous problems with css only seem to appear in certain
UAs under certain conditions if you send it as text/css. It would be
much safer then to advertise it as text/plain, no?
Ah. You mean if you do what you are SUPPOSED to do?
Click to expand...

The question, if any, is rather why you would want to omit the namespace
rather than the doctype declaration artefact once you've jumped on the
XHTML bandwaggon.
 
M

Micah Cowan

Eric B. Bednarz said:
David Dorward said:
Micah Cowan wrote:
Click to expand...

[It's... the namespaces; if you don't have a life anyway, start your
next spare weekend ahead with:

If you're not using XHTML, that's not surprising, is it?
Click to expand...

I'm using XHTML; All of my XHTML is also 100% valid HTML. XHTML
is very unlikely to be recognized "specially" by the majority of
user agents in use today, so I must take pains to ensure that it
is readable by XHTML-unaware agents.
Some of the numerous problems with css only seem to appear in certain
UAs under certain conditions if you send it as text/css. It would be
much safer then to advertise it as text/plain, no?
Click to expand...

No, and the differences are obvious. A browser which claims to
support CSS but has problems with text/css is broken, whereas a
browser which has problems with application/xhtml+xml is simply
not new enough to take advantages of the XML properties of
XHTML. Serving CSS as text/css breaks spec conformance,
whereas serving XHTML as text/html is specifically sanctioned by
the spec. It would be impossible to provide a clean transition
from (SGML-based) HTML to XHTML without serving it as text/html
until a reasonable percentage of user agents support XHTML
properly. But I take it you're only interested in a very limited
number of user agents, if you're not doing this. Just don't look
down at those of us who are *also* conforming diligently to the
specifications, and have chosen the significantly more practical
option.

(Above is Mr. Dorward's quote)

"Supposed" to do? On what do you base this assumption? Have you
*read* the XHTML 1.0 spec? (Or are you using a newer version,
even less likely to be supported in the wild?) Check out section
5.1 and appendix C, in particular.
The question, if any, is rather why you would want to omit the namespace
rather than the doctype declaration artefact once you've jumped on the
XHTML bandwaggon.
Click to expand...

I don't consider the doctype an "artefact": it is still very much
a part of XML, still very important to validation (until
Schemeaas become fully a part of the XML core, replacing DTDs
entirely [not to mention breaking compatibility with SGML]);
whereas the explicit xhtml namespace serves very little purpose
when the html is not embedded, and is entirely redundant when the
doctype declaration is included. But YMMV, I guess.

-Micah
 
D

David Dorward

Micah said:
I'm using XHTML; All of my XHTML is also 100% valid HTML.
Click to expand...

No <link>, no <meta>, and a ">" character after every line break and
image[1]?

And somehow you manage to have an HTML Doctype AND an XHTML Doctype in the
same document, despite their being mutually exclusive?
(Above is Mr. Dorward's quote)

"Supposed" to do? On what do you base this assumption? Have you
*read* the XHTML 1.0 spec? (Or are you using a newer version,
even less likely to be supported in the wild?) Check out section
5.1 and appendix C, in particular.
Click to expand...

Quote: In summary, 'application/xhtml+xml' SHOULD be used for XHTML Family
documents.

Cite: http://www.w3.org/TR/xhtml-media-types/

[1] Or do you use <object> for images?
 
M

Micah Cowan

David Dorward said:
Micah said:
I'm using XHTML; All of my XHTML is also 100% valid HTML.
Click to expand...

No <link>, no <meta>, and a ">" character after every line break and
image[1]?

And somehow you manage to have an HTML Doctype AND an XHTML Doctype in the
same document, despite their being mutually exclusive?
Click to expand...

You obviously have *not* read the XHTML spec. The XHTML Doctype
*is* an HTML doctype. There are more than one (many, in
fact). And both XHTML (even 2.0) and HTML certainly *do* have link
and meta. WTH are you talking about; ">" character after every
line break and image? That has nothing to do with either XHTML or
HTML, and it wouldn't be legal XML/SGML, let alone XHTML/HTML.

So... what on *earth* are you talking about? Do you have *any*
semblance of a reference to actually make your claims sound less
ridiculous?
Quote: In summary, 'application/xhtml+xml' SHOULD be used for XHTML Family
documents.

Cite: http://www.w3.org/TR/xhtml-media-types/
Click to expand...

Sure, once that is widely supported. And to finish your quote:

and the use of 'text/html' SHOULD be limited to HTML-compatible
XHTML 1.0 documents

-Micah
 
N

Nicolai P. Zwar

Micah Cowan wrote:

No, and the differences are obvious. A browser which claims to
support CSS but has problems with text/css is broken, whereas a
browser which has problems with application/xhtml+xml is simply
not new enough to take advantages of the XML properties of
XHTML. Serving CSS as text/css breaks spec conformance,
whereas serving XHTML as text/html is specifically sanctioned by
the spec. It would be impossible to provide a clean transition
from (SGML-based) HTML to XHTML without serving it as text/html
until a reasonable percentage of user agents support XHTML
properly.
Click to expand...


That's why I'm serving on my own page even XHTML 1.1 as text/html. I
figure once newer browsers that recognize application/xhtml+xml will be
used to a wider extent, it'll only be a small step to fix up the content
declarations. Piece of cake, really. Serving XHTML as text/html seems to
be the most prudent thing to do right now.
 
T

Toby A Inkster

Nicolai said:
That's why I'm serving on my own page even XHTML 1.1 as text/html. I
figure once newer browsers that recognize application/xhtml+xml will be
used to a wider extent, it'll only be a small step to fix up the content
declarations. Piece of cake, really. Serving XHTML as text/html seems to
be the most prudent thing to do right now.
Click to expand...

A nice compromise is to serve at application/xhtml+xml to browsers that
accept it, and text/html to others.

A simple (but not 100% reliable) method of doing this is sniffing the
User-Agent HTTP header. If User Agent contains "Gecko" or "Opera/7" or
"Opera 7" but not "Safari", then use application/xhtml+xml. Otherwise use
text/html.

A better way is to look at the Accept HTTP header.
 
T

Toby A Inkster

Micah said:
You obviously have *not* read the XHTML spec. The XHTML Doctype
*is* an HTML doctype. There are more than one (many, in
fact). And both XHTML (even 2.0) and HTML certainly *do* have link
and meta. WTH are you talking about; ">" character after every
line break and image? That has nothing to do with either XHTML or
HTML, and it wouldn't be legal XML/SGML, let alone XHTML/HTML.
Click to expand...

I think David was referring to the fact that say:

<br />

in HTML 4 Transitional *should* be parsed as a line break followed by a
">" character. This is because the SGML shorttags feature makes the "/"
close the BR element, so the ">" character afterwards is spare.

If we apply the same logic to:

<link />

and

<meta />

we see that every such occurance will dump a raw ">" into the document
head, where such data is invalid (All data inside the document head must
be inside other elements, like TITLE, STYLE, SCRIPT, etc).
 
D

David Dorward

Micah said:
David Dorward said:
Micah said:
I'm using XHTML; All of my XHTML is also 100% valid HTML.
Click to expand...

No <link>, no <meta>, and a ">" character after every line break and
image[1]?

And somehow you manage to have an HTML Doctype AND an XHTML Doctype in
the same document, despite their being mutually exclusive?
Click to expand...

You obviously have *not* read the XHTML spec.
Click to expand...

I have actually, but maybe I'm forgetting something...
The XHTML Doctype *is* an HTML doctype. There are more than one (many, in
fact).
Click to expand...

Can you provide a specific reference?
And both XHTML (even 2.0) and HTML certainly *do* have link
and meta.
Click to expand...

That's true - but:

<link (attributes)> is not valid in XHTML.
and
WTH are you talking about; ">" character after every
line break and image? That has nothing to do with either XHTML or
HTML, and it wouldn't be legal XML/SGML, let alone XHTML/HTML.
Click to expand...

If you have (for instance) <img src="dot" alt="dot" /> in an XHTML document,
it should render as:

..

however, in an HTML document it should render as:

..>
So... what on *earth* are you talking about? Do you have *any*
semblance of a reference to actually make your claims sound less
ridiculous?
http://www.cs.tut.fi/~jkorpela/html/empty.html


Sure, once that is widely supported. And to finish your quote:

and the use of 'text/html' SHOULD be limited to HTML-compatible
XHTML 1.0 documents
Click to expand...

In other words, you are supposed to use application/xhtml+xml, but if you
use text/html despite this you are only supposed to do with appendix c
conforming documents.
 
M

Micah Cowan

Toby A Inkster said:
I think David was referring to the fact that say:

<br />

in HTML 4 Transitional *should* be parsed as a line break followed by a
">" character. This is because the SGML shorttags feature makes the "/"
close the BR element, so the ">" character afterwards is spare.

If we apply the same logic to:

<link />

and

<meta />
Click to expand...

But that's not correct. AIUI, SGML shorttags would be:
<element/ content />. If it parsed <br /> the same way, it'd
be broken.

Any HTML parser which *truly* understands SGML should be given
the proper declaration for XML... and voila! It's an XML
parser. Then it can parse XHTML *exactly* as expected. Even
without it, the HTML declaration (given in section 20 of the spec).

But it has at any rate become quite clear to me that our goals
for using XHTML are fundamentally different; and that our very
different recommendations for how we write (and serve) XHTML, are
both valid for our very separate intentions as to how we wish our
content to function. David desires only that his content function
under XHTML-aware processing agents; whereas I very much wish it
to behave well under HTML 4.01-conforming user agents (as well as
XHTML-aware processing agents).

-Micah
 
M

Micah Cowan

Toby A Inkster said:
A nice compromise is to serve at application/xhtml+xml to browsers that
accept it, and text/html to others.
Click to expand...

An excellent idea.
A simple (but not 100% reliable) method of doing this is sniffing the
User-Agent HTTP header. If User Agent contains "Gecko" or "Opera/7" or
"Opera 7" but not "Safari", then use application/xhtml+xml. Otherwise use
text/html.

A better way is to look at the Accept HTTP header.
Click to expand...

Can you tell me whether the majority (or, hopefully, all) of
XHTML-aware user agents announce this in their Accept header?
Also, is it possible to determine (I'm guessing not) whether,
e.g., XHTML 2.0 is accepted?

Of course, people who don't have configure-access to their web
server (or who use a crappy web server) cannot implement this
solution... :-(

-Micah
 
D

David Dorward

Micah said:
Any HTML parser which *truly* understands SGML should be given
the proper declaration for XML... and voila! It's an XML
parser.
Click to expand...

Why? HTML is an SGML application. Why should it become an XML parser just
becuase you give it an XML document? (I agree that an HTML/XHTML parser
should, but that isn't what you said)
David desires only that his content function under XHTML-aware processing
agents; whereas I very much wish it to behave well under HTML
4.01-conforming user agents (as well as XHTML-aware processing agents).
Click to expand...

Wrong. I desire that we all get our facts straight.
 
D

David Dorward

Micah said:
Can you tell me whether the majority (or, hopefully, all) of
XHTML-aware user agents announce this in their Accept header?
Click to expand...

Mozilla does. Opera does (but says it prefers text/html), Safari just says
it will accept anything. (A test shows that Safari does understand XHTML):

http://dorward.me.uk/tmp/xhtml/short.htm (served as text/html)
http://dorward.me.uk/tmp/xhtml/short.xhtml (served as application/xhtml+xml)
Also, is it possible to determine (I'm guessing not) whether,
e.g., XHTML 2.0 is accepted?
Click to expand...

No
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

XHTML - how extend/create ELEMENT body in my DTD? 0
CSS not visible with XHTML decleration 0
CSS not visible with XHTML decleration 6
XHTML question 8
xhtml example of marked up image 2
Newbie XHTML question. 5
XHTML Doctype? 14
Can someone tell me if this a real tracker? Or is it one designed to show you a different message at certain times, ie. acting like one? 0

Members online

Total: 39 (members: 1, guests: 38)
Robots: 213

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top