XHTML namespace declararion: needed or not?

Discussion in 'HTML' started by David Higgins, Oct 15, 2003.

  1. 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
    David Higgins, Oct 15, 2003
    #1
    1. Advertising

  2. David Higgins

    altamir Guest

    (David Higgins) wrote in
    news::

    [snip]

    > 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" ?
    >


    http://www.tantek.com/XHTML/Test/minimal.html

    --
    altamir
    altamir, Oct 15, 2003
    #2
    1. Advertising

  3. David Dorward, Oct 15, 2003
    #3
  4. David Higgins wrote:

    > I think I understand what the DOCTYPE is all about, but what is the
    > namespace designator for?


    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)

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me - http://www.goddamn.co.uk/tobyink/?id=132
    Toby A Inkster, Oct 15, 2003
    #4
  5. Micah Cowan wrote:

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


    > 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.


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

    --
    David Dorward http://dorward.me.uk/
    David Dorward, Oct 15, 2003
    #5
  6. David Higgins

    Micah Cowan Guest

    (David Higgins) writes:

    > 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"?> ?


    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" ?


    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
    Micah Cowan, Oct 15, 2003
    #6
  7. David Higgins

    Micah Cowan Guest

    David Dorward <> writes:

    > David Higgins wrote:
    >
    > > (2) what effect, if any, is there of leaving out
    > > xmlns="http://www.w3.org/1999/xhtml"

    >
    > 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.


    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
    Micah Cowan, Oct 15, 2003
    #7
  8. David Dorward <> writes:

    > Micah Cowan wrote:


    [It's... the namespaces; if you don't have a life anyway, start your
    next spare weekend ahead with:
    <http://groups.google.com/groups?selm=>
    otherwise, just resolve to tagsoup. It's... the web, and stuff, you know.]

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

    >
    >> I have never had this issue.


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

    >> 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.


    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?


    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.

    --
    "On Usenet, parodies fail, because Usenet itself is a parody."
    --Korpela's 13th Law about Usenet
    Eric B. Bednarz, Oct 16, 2003
    #8
  9. Micah Cowan <> wrote in message news:<>...

    <--snip-->

    Thanks Micah. Very helpful!


    Dave
    David Higgins, Oct 16, 2003
    #9
  10. David Higgins

    Micah Cowan Guest

    Eric B. Bednarz <> writes:

    > David Dorward <> writes:
    >
    > > Micah Cowan wrote:

    >
    > [It's... the namespaces; if you don't have a life anyway, start your
    > next spare weekend ahead with:
    > <http://groups.google.com/groups?selm=>
    > otherwise, just resolve to tagsoup. It's... the web, and stuff, you know.]
    >
    > >>> Mozilla fails to recognise it as XHTML and treats it like any other XML
    > >>> document.

    > >
    > >> I have never had this issue.

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


    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.

    >
    > >> 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.

    >
    > 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?


    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.

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


    (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.


    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
    Micah Cowan, Oct 16, 2003
    #10
  11. Micah Cowan wrote:

    > I'm using XHTML; All of my XHTML is also 100% valid HTML.


    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?

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

    >
    > (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.


    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?

    --
    David Dorward http://dorward.me.uk/
    David Dorward, Oct 16, 2003
    #11
  12. David Higgins

    Micah Cowan Guest

    David Dorward <> writes:

    > Micah Cowan wrote:
    >
    > > I'm using XHTML; All of my XHTML is also 100% valid HTML.

    >
    > 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?


    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?

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

    > >
    > > (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.

    >
    > Quote: In summary, 'application/xhtml+xml' SHOULD be used for XHTML Family
    > documents.
    >
    > Cite: http://www.w3.org/TR/xhtml-media-types/


    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
    Micah Cowan, Oct 17, 2003
    #12
  13. 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.



    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.

    --
    Nicolai Zwar
    http://www.nicolaizwar.com
    Nicolai P. Zwar, Oct 17, 2003
    #13
  14. Nicolai P. Zwar wrote:

    > 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.


    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.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me - http://www.goddamn.co.uk/tobyink/?id=132
    Toby A Inkster, Oct 17, 2003
    #14
  15. Micah Cowan wrote:

    > 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.


    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).

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me - http://www.goddamn.co.uk/tobyink/?id=132
    Toby A Inkster, Oct 17, 2003
    #15
  16. Micah Cowan wrote:
    > David Dorward <> writes:
    >> Micah Cowan wrote:
    >>
    >> > I'm using XHTML; All of my XHTML is also 100% valid HTML.

    >>
    >> 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?

    >
    > You obviously have *not* read the XHTML spec.


    I have actually, but maybe I'm forgetting something...

    > The XHTML Doctype *is* an HTML doctype. There are more than one (many, in
    > fact).


    Can you provide a specific reference?

    > And both XHTML (even 2.0) and HTML certainly *do* have link
    > and meta.


    That's true - but:

    <link (attributes)> is not valid in XHTML.
    and
    <link (attributes) /> is not valid in HTML.

    > 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.


    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

    >> >> > Ah. You mean if you do what you are SUPPOSED to do?
    >> >
    >> > (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.

    >>
    >> Quote: In summary, 'application/xhtml+xml' SHOULD be used for XHTML
    >> Family documents.
    >>
    >> Cite: http://www.w3.org/TR/xhtml-media-types/

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


    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.

    --
    David Dorward http://dorward.me.uk/
    David Dorward, Oct 17, 2003
    #16
  17. David Higgins

    Micah Cowan Guest

    Toby A Inkster <> writes:

    > Micah Cowan wrote:
    >
    > > 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.

    >
    > 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 />


    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
    Micah Cowan, Oct 17, 2003
    #17
  18. David Higgins

    Micah Cowan Guest

    Toby A Inkster <> writes:

    > Nicolai P. Zwar wrote:
    >
    > > 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.

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


    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.


    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
    Micah Cowan, Oct 17, 2003
    #18
  19. Micah Cowan wrote:

    > Any HTML parser which *truly* understands SGML should be given
    > the proper declaration for XML... and voila! It's an XML
    > parser.


    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).


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

    --
    David Dorward http://dorward.me.uk/
    David Dorward, Oct 17, 2003
    #19
  20. Micah Cowan wrote:

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

    >
    > Can you tell me whether the majority (or, hopefully, all) of
    > XHTML-aware user agents announce this in their Accept header?


    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?


    No

    --
    David Dorward http://dorward.me.uk/
    David Dorward, Oct 17, 2003
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    7
    Views:
    868
  2. chronos3d
    Replies:
    9
    Views:
    762
    Andy Dingley
    Dec 5, 2006
  3. Usha2009
    Replies:
    0
    Views:
    1,118
    Usha2009
    Dec 20, 2009
  4. xhtml champs
    Replies:
    0
    Views:
    455
    xhtml champs
    Aug 1, 2011
  5. xhtml champs
    Replies:
    0
    Views:
    1,015
    xhtml champs
    Aug 2, 2011
Loading...

Share This Page