Re: HTML Validator HTTP Accept

Sierk Bornemann wrote:
> Am 11.12.2008 um 21:48 schrieb David Dorward:

>> If the content is generated, then whatever is generating it can be set
>> to generate differently marked up content depending on the URI.
>> Converting XHTML to HTML is relatively trivial with XSLT or libtidy.
> 
> Have you ever seen a content management system or blog system out there,
> which is able to do that?

Yes (but its propriety and not available to the public).

> If that would be a veritable and acceptable solution, why hasn't it wide
> spread?

Because few people care about serving XHTML with the right content type.

> Imagine, what disk space explosion would be generated on the different
> webservers

A tiny one, since:

(a) It can be done dynamically

and

(b) HTML generally doesn't take up that much space

, if that would come into real scenario. And all that only to
> provide two different content types (HTML and XHTML) and to please one
> particular web browser, which is not capable of the recommended XHTML
> Mimetype (Internet Explorer)? Can you guess, that the expense and costs
> of your "solution" might not in due proportion to what is aimed?

People seem to be jumping through amazing numbers of hoops to satisfy IE
as it is. What is one more?

I'm more amazed at the effort some people go to to serve HTML-compatible
XHTML as application/xhtml+xml when everything significant out there
will happily munch it up as text/html.

>> ... but frankly - XHTML provides little advantage in most cases. So
>> unless there was a real benefit to it, I'd just generate HTML from the
>> outset and not worry about content negotiation.
> 
> This is a declaration of death for XHTML at all and the mimetype
> application/xhtml+xml. 

Ian Hixie did some tests using Google's database, he says:

< Hixie> but iirc in one study i did application/xhtml was 0.0044%,
xhtml as text/xml or application/xml wasn't visible at all, and xhtml
was about 15% of all text/html
< Hixie> (from memory, so those numbers are likely wrong, but they're in
the right ballpark)

XHTML was pretty much still born, which is unsurprising since its
benefits are:

(a) More easily machine processable

... but most people use templates, not DOM, XSLT or anything else that
depends on it being anything other then text.

(b) Mixed namespaces

... but most people want it to work in Internet Explorer.

It is possible to write an XML+SVG document (for instance) and serve it
up to clients that support XHTML, and then replace the SVG with an img
element that references a gif for user agents that don't support XHTML -
but most people don't go to that much effort.

If all you are doing is changing the Doctype and content type (or just
the content type) - what's the point?

It's a nice language, but the vast majority of people get everything
they need from HTML and the vast majority of people who use XHTML treat
it as HTML with a shiny version number on it.

At some stage I must get around to looking at XHTML 2. It looks like it
might have some nice features ... of course browser support for it is
awful, so it would have to be transformed into something more widely
supported before it could be used on the WWW.

>> Umm. Err. Why are you imposing such ridiculous constraints?
>>
>> If you want to do content negotiation then:
> 
> Please no theoretical Blahblah: please give me a real usable code
> example in apache configuration code that can be used in real world
> needs, how to solve the situation WITHOUT doubling the content
> physically, WITHOUT symlinking the content files on the webserver,
> WITHOUT content negotiation (which needs a minimum of two physical
> files) and WITHOUT relying on accept headers and WITHOUT using
> mod_rewrite in combination with accept headers.

Umm. No. I don't have such code handy, or know if it is possible to
achieve that. If I wanted to to content negotiation then I would use
other methods.

As I said earlier - content negotiation is worthless unless the content
is actually different. If the content is that different then either
there are going to be multiple static files (in which case the built in
content negotiation system in Apache can do the job), or something on
the server will be dynamically generating the resources for the client
(in which case, it can).

> Your proposed Quality
> Values (for example qs=0.999 .xhtml)

Quality values appear in the HTTP 1.0 spec, which was published in 1996
- at the time, my experience of the Internet was about an hour of being
frustrated by AOL on dial up. I certainly didn't propose the feature.

> do only work, if the content does exist multiple times.

Incorrect.

> But this multiple existance of so far identical
> web content and only differing in file extension is unacceptable and
> unreachable for the most scenarios out there or might be.

The only reason you've given for that is that they consume a (relatively
small) amount of a cheap resource (hard disk space).

> ONE example for real world use, that fits the needs, please. Only one
> simple example that can be chosen in real world and that fits real world
> needs.
> Please specify or link to configuration code for Apache to show a solution.

Since you've gone out of your way to RULE OUT all the simple solutions - no.

-- 
David Dorward                               <http://dorward.me.uk/>

Received on Thursday, 11 December 2008 23:46:50 UTC