RE: Indicating browser support for XHTML1.0

Hello Chris, dear other list members.

> -----Original Message-----
> I can decide at run-time - on a  session-by-session basis - whether to
> generate XHTML1.0-conformant code (tested using the W3C validation
> service), or to drop back to HTML4.01 for the 'legacy' browsers.
I think you needn't.

> I can offer the best presentation (and better performance) using
> XHTML, so obviously I would like to use this whenever the user has a
> browser which can support it.
>
> My problem: how do I tell which browsers support XHTML1.0?
You needn't.

Common problems of XHTML are:

1. The XML Declaration

Browsers might display SGML processing instructions, which start with <? and
end with ?>. This affects the encoding you must use. Since XHTML documents
are XML documents, all encodings that are not US-ASCII-7, UTF-8 or UTF-16
must be declared using the XML Declaration, wich is an SGML (not XML)
processing instruction like <?xml version="1.0" encoding="iso-8859-1"?>. So
don't use ISO-8859-1 or UTF-8, use ASCII only.

With most common browsers, UTF-8 also works as long as you include a
declaration of your use of UTF-8 like this in the html page head:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

So use no XML declaration and because of that use either US-ASCII-7 or UTF-8
as your character encoding.
This doesn't mean you can't use "special" characters like umlauts or chinese
letters, they simple need to be encoded using their character entity
representations, e.g. like &#252; or, if you include a doctype declaration,
&uuml; for the German "ü".


Short: Don't use an XML declaration, use US-ASCII-7 and you are always, or
UTF-8 and you are most times, safe.


2. Empty Elements

Since all elements need to be closed, you might try <br></br> or <hr></hr>.
But this will result in displaying two line breaks or two horizontal rulers
in most browsers. It is required to use the EmptyElemTag of XML. But be
aware, <br/> and <hr/> will also fail in several browsers including Netscape
Navigator 4.x because they take the / as part of the element name and try to
interpret a "br/" tag, which, of course, they do not know. So you need to
include at least one whitespace before the /, write <hr /> and <br />. I
know that HotJava and Swing's JEditorPane have problems with that and
display / or />, but they are not commonly in use and it's their bug and
faulty behavior.

Short: use <br /> and <hr />, do not use <br></br> or <br/>


3. CDATA Sections

They won't work in most browsers. Don't use them. For style sheets and
scripting still use comments or nothing. For everything else, do not
generate CDATA sections.

Short: Do not use CDATA Sections.


This is my personal experience. I do not guarantee for anything ;)

I have tested this since Mozilla around Amaya, M16, Opera 5.12, Opera 3.60,
Opera 4.0, Netscape 6.1, IE 5.0, IE 5.5, IE 6.0, some versions of Konqueror,
w3m and lynx and from time to time with some Amiga browsers like AWeb,
iBrowse, Voyager.

I have not tested this on Mosaic, Arena, Chimera, Arachne, Voyager (QNX),
Voyager (MorphOS), EmacsW3.


Greetings

Christian

> Inspecting the HTTP headers produced by MSIE6. NS6.2 and Opera 6, I
> see that NS6.2 includes the 'application/xhtml+xml' mime type in its
> 'Accept' list, but neither of the others appear to have anything that
> could help (all three function correctly with the generated XHTML code
> I've tested).
>
> The 'text/html' type does not help with version numbers, nor does the
> new mime type.
If you
- generate only a single version, serve it as text/html always.
- generate both versions, currently serve them as text/html always and wait
for browser bug fixes and public clearification of the XHTML MIME Type
discussion until you decide which MIME type you use to serve your documents.
Sometimes browsers tend to display the source code if you serve XHTML as
text/xhtml, application/xhtml+xml or similar.

> I've studied the June and Oct  threads in this list on this new mime
> type, and its not clear to me that, even with IETF approval and its
> implementation by all browser vendors, it would actually provide the
> distinction I am looking for.
>
> Is 'application/xhtml+xml' intended to provide this distinction, or is
> there anything else in the W3C recommendations which would serve this
> purpose?
I also already asked for quick clearification. All we can do now is sit and
wait. Björn Hörmann from Germany is doing somewhat activ on that topic, I
hope he is able to move something towards the right direction.


> Has there been any consideration given to indicating agent capability
> at the major/minor version level?
This is not a task of the W3C, it is a task of the browser manufacturers.
Opera and Mozilla.org clearly state what they support and what they do not
support. For Internet Explorer, I was unable to find such official
information anywhere on *.microsoft.com. But I know Internet Explorer (even
version 6) lacks of full HTML 4 and XHTML support. <abbr/>, <acronym/>, <q/>
elements and several attributes do not work.
But there are around 100 different browsers/versions out there, it cannot be
the task of the W3C to either test all browsers or prefer certain browsers
and test them. They are officials and need to behave neutral.


Greetings, I hope I could help you.

Christian

Received on Wednesday, 21 November 2001 14:04:21 UTC