xml-dev - Re: XML Client detection

[David Brownell <david-b@pacbell.net>]

In short, you can't just assume XHTML since you're trying to address
older "v2" browsers.  So you really do need to look at the "User-Agent"
in the HTTP request -- but it's not an "XML capable browser" issue,
just a "requires broken HTML" issue.

Again, my bias would be to treat old browsers as the exception case,
and just serve up XHTML unless you recognize an "old" browser.  (Of
course, provide an "old browser" button in the XHTML page too.)  But
whether you treat "old" or "new" as the exception is your call.

For what it's worth, I just use the "transitional" XHTML DTD since
HTML browsers don't tend to handle enough of CSS to use "strict".
I've found that providing valid XHTML tends to make browsers like
Netscape 4.x handle CSS better ... and even then, there are some
valid constructs they won't quite be happy with!  :-)

Sorry I don't have a list of such browsers, but you should be able
to have your webserver tell you about the browsers your readers use.

- Dave



rev-bob@gotc.com wrote:
> 
> > Since your output choices are currently limited to HTML and XHTML, I'd
> > be sorely tempted to just default to XHTML, and give folk an option to
> > go to HTML output if that breaks.
> >
> > The reason is that most reasonably well crafted XHTML will be accepted by
> > both HTML and XML aware browsers, with the primary known exception being
> > very old browsers ("version 2") that you may not support anyway.
> 
> The trouble with that is, I kind of make a crusade out of accessibility.  Just about
> anybody can access my HTML, because I've taken care to include several legacy
> support tricks (such as a SCRIPT element inside a NOSCRIPT element, which is
> specifically designed to work around the fact that NN2 doesn't know what NOSCRIPT
> means) which are spec-illegal yet necessary for old-client support.
> 
> With the XHTML pages, I'm trying to get away from that.  Since old browsers don't
> understand XML, I can drop a lot of the antiquated hacks and make the XHTML code a
> bit cleaner.  Hence, the need for a client sniffer - send the older browsers to the HTML
> code which makes allowances for them, and shamelessly take advantage of the XML-
> compliant browsers' features.
> 
> > You only really need XML support in the client if you're trying to use
> > the XML/CSS (or eventually XML/XSLT) style rendering.  Since I couldn't
> > use IE5 support for that (no list or link support, or preformatted text),
> > and Mozilla's not prime-time yet, I'd not bother with that approach for
> > some time to come.
> 
> Look at it this way.  If I get the sniffer working, I can do things like morph FONT FACE
> tags into CSS styles for the XHTML version, thus ultimately bringing the XHTML
> version several steps closer to the ideal of divorcing content from presentation.  That's
> my goal; I'm not looking for XML support because I need it, but because excluding
> browsers without it will let me get closer to "pure code" in those pages.
> 
>  Rev. Robert L. Hood  | http://rev-bob.gotc.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)