content negotiation and parsing page contents

#1 February 6th, 2006, 04:55 PM

I'm trying to undestand the impact of using content negotiation when
rendering my Web pages to various different browsers as I would like to
use the XHTML Strict DOCTYPE declaration. Reading the W3C guidelines,
if I render as 'text/html' then there are some backward compatibility
issues I need to worry about. Does this mean that the page must be
rendered in one way if I use the "application/xhmlt+xml" content type
and another if I use the "text/html" content type? This would mean
parsing of every page on the site.... Or, if I follow the backward
compatibility rules from the W3C, will it render properly regardless
of the content-type for a particular request?

Thanks

#2 February 6th, 2006, 07:55 PM

wardy wrote:
[color=blue]
> I'm trying to undestand the impact of using content negotiation when
> rendering my Web pages to various different browsers as I would like to
> use the XHTML Strict DOCTYPE declaration. Reading the W3C guidelines,
> if I render as 'text/html' then there are some backward compatibility
> issues I need to worry about.[/color]

If you serve as text/html then some browsers will render the document in
ways you don't like (splattering the page with ">" characters whereever you
have an <img />, <br />, <hr /> and so on).
[color=blue]
> Does this mean that the page must be rendered in one way if I use the
> "application/xhmlt+xml" content type and another if I use the "text/html"
> content type?[/color]

If it is served as text/html then it will be parsed with a tag soup slurper.

If it is served as application/xhtml+xml then it will be parsed with an XML
parser (which means IE will prompt user's to download it, and Firefox won't
render it until the entire document is downloaded and parsed, and will spit
errors at the user instead of trying to recover if the document isn't well
formed).

There are no differences in how browsers are supposed to render XHTML and
HTML (although there /are/ rules as to how CSS is applied which could
influence the rendering (e.g. class selectors are HTML only and don't apply
to XHTML, and the root element is <html> instead of <body>).
[color=blue]
> This would mean parsing of every page on the site....[/color]

Browsers have to parse every page they display.
[color=blue]
> Or, if I follow the backward compatibility rules from the W3C, will it
> render properly regardless of the content-type for a particular request?[/color]

No. At present, unless you have need of something that only XHTML can
provide on the client (like mixed-namespace documents), stick to HTML. (By
all means _write_ XHTML, but transform it to HTML before it gets to the
client).

The Mozilla FAQ states that the only reason application/xhtml+xml has a
higher quality value than text/html in the Accept request header, is so
that the browser will get MathML versions of documents. They advise the use
of HTML 4.01 Strict.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

#3 February 6th, 2006, 10:25 PM

wardy wrote:[color=blue]
> I'm trying to undestand the impact of using content negotiation when
> rendering my Web pages to various different browsers as I would like to
> use the XHTML Strict DOCTYPE declaration. Reading the W3C guidelines,
> if I render as 'text/html' then there are some backward compatibility
> issues I need to worry about.[/color]

Yep. It's not that onerous unless your pages are generated by XML
tools that don't grok "Appendix C". If that is an issue, filter them
through mod_xhtml. Or - if they're static - equivalent preprocessor.
[color=blue]
> Does this mean that the page must be
> rendered in one way if I use the "application/xhmlt+xml" content type
> and another if I use the "text/html" content type?[/color]

That's up to the user agent. Normal browsers are happy with text/html
and HTML 4, but will accept xhtml as a second choice. MSIE will _only_
accept xhtml when it's served as text/html+tagsoup. But if you're
(also) serving to non-browsers, you'll have to work with whatever
they like.

--
Nick Kew

#4 February 6th, 2006, 11:15 PM

David Dorward wrote:[color=blue]
> (e.g. class selectors are HTML only and don't apply to XHTML [...]).[/color]

Since when? Class selectors apply to any XML document in which the UA
has namespace specific knowledge of a class attribute. The spec
explicitly states that and goes on to provide examples of the SVG and
MathML class attributes, so there is no reason why they don't apply to
XHTML.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

#5 February 7th, 2006, 08:35 AM

Lachlan Hunt wrote:
[color=blue]
> David Dorward wrote:[color=green]
>> (e.g. class selectors are HTML only and don't apply to XHTML [...]).[/color]
>
> Since when?[/color]

Since CSS 2.

"For style sheets used with HTML"

-- http://www.w3.org/TR/CSS2/selector.html#class-html
[color=blue]
> Class selectors apply to any XML document in which the UA
> has namespace specific knowledge of a class attribute.[/color]

Ah. I see they've changed that in CSS 2.1, thank goodness for that. Still a
working draft though.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

#6 February 8th, 2006, 05:55 PM

Great....thanks for the info all. I thought that I had read that
rendering XHTML to MSIE as text/html actually invokes almost standards
mode, and not quirks/tag soup mode. Is that not correct?

When rendering XHTML as text/html, would I need to worry about putting
the meta tag for the content type if I am already setting this in th
headers on the server? I wouldn't think so, but then how do I indicate
to use a different charset than the default UTF-8 or UTF-16 designation
for a text/html page?

Thanks

#7 February 8th, 2006, 06:05 PM

wardy wrote:[color=blue]
> Great....thanks for the info all. I thought that I had read that
> rendering XHTML to MSIE as text/html actually invokes almost standards
> mode, and not quirks/tag soup mode. Is that not correct?[/color]

AFAIK MSIE doesn't have an 'almost standards' mode, just standards and
quirks. And both (all three in other browsers) rendering modes are
HTML/tag soup rendering modes. Rendering XHTML as XHTML is something
else again.

Steve

#8 February 8th, 2006, 06:05 PM

On 8 Feb 2006, wardy wrote:
[color=blue]
> but then how do I indicate
> to use a different charset than the default UTF-8 or UTF-16 designation
> for a text/html page?[/color]

That depends on your server software; read
http://www.w3.org/International/O-HTTP-charset.html

There is no default encoding (charset) for a "text/html page".

--
All free men, wherever they may live, are citizens of Denmark.
And therefore, as a free man, I take pride in the words "Jeg er dansker!"

#9 February 8th, 2006, 07:15 PM

David Dorward wrote:
[color=blue]
> If you serve as text/html then some browsers will render the document in
> ways you don't like (splattering the page with ">" characters whereever you
> have an <img />, <br />, <hr /> and so on).[/color]

Yes, and if you don't wear the tinfoil hat then the Chinese Google Rays
will eat you.

In practice, out in the real world, this just doesn't happen. It
_could_ happen (apparently a variant of emacs that grew beyond reading
mail and sprouted a web client did this), but it's just not something
to worry about.

#10 February 8th, 2006, 07:25 PM

Andy Dingley wrote:
[color=blue]
> In practice, out in the real world, this just doesn't happen. It
> _could_ happen (apparently a variant of emacs that grew beyond reading
> mail and sprouted a web client did this)[/color]

Umm. No. That's emacs. And the standard web browser for emacs, and that's
just one example. Anything that deals with HTML as SGML will do that.
[color=blue]
> , but it's just not something to worry about.[/color]

Advantages of serving XHTML as text/html to the client: Zip
Disadvantages of serving XHTML as text/html to the client: Minor

The disadvantages outweigh the advantages. Welcome back HTML 4.01.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

What is Bytes?

Popular Articles