Re: HTML Validator HTTP Accept

Sierk Bornemann wrote:
>
> Am 12.12.2008 um 07:22 schrieb David Dorward:
>>
>> I gave my reasons for not providing such code.
>
> Lame and very weak argument, David. If you propagate not to rely on 
> accept headers
I don't, the closest I've come to that is advocating the use of 
alternative URIs to override content negotiation based on accept headers 
(which is a LONG way from advocating the abolishment of it). As 
mentioned repeatedly - if you do content negotiation use the Accept 
header, but use it correctly.

>> "Daily practical use" is "Use text/html".
>
> And if I WANT/NEED my web content be parsed by the XML parser of a 
> browser, if possible?
If you "want" it, then you have to accept that you have to do some work 
to achieve your desires.

If you "need" it, then serving as text/html should be either 
unacceptable, or you should be providing different content 
representations as well as different content types. In which case, you 
either have some process generating the representations on demand (in 
which case it should be doing so based on the accept header, preferably 
with a URI override) or you have the two representations stored in 
separate files (in which case you can use the Apache built in content 
negotiation).

>> Exactly - don't use application/xhtml+xml for typical webpages.
>
> So only for intranet and IE-free zones.
No. Only for cases where you need something that HTML can't do, and at 
that point, if you want things to "work" in Internet Explorer then you 
have to provide alternative representations of the information.
> And that's far from reality. And you know that. What you are proposing 
> is the death of XHTML at all and the death of that particular mimetype.
> That's the total opposite of what's the interests of the W3C
Umm... http://w3.org/TR/html5/
> and is the opposite of all work behind XHTML.
Most XHTML work from the W3C, as far as I know, is on XHTML 2.0, which 
as far as I can tell (and mentioned) is going to be a nice language for 
writing documents in but won't be supported by any major browser. I'm 
seriously considering moving my stored content to it (Docbook is also a 
possibility) - but I'll be transforming it to HTML for browsers because 
it is what they can cope with.

I'm not going to start serving XHTML to clients without a practical reason.

text/html - supported by everything that matters.

application/xhtml+xml - not supported by Internet Explorer.

If I'm not making use of a feature that requires XHTML, then using XHTML 
is silly.

>> (b) Explicitly reminds people to pay attention to q values
>
> AND Accept Headers. And that's we are talking about.
> BOTH and depending on each other. And that's the big difference to 
> what you talk about.
Err. q values are part of the Accept header definition. I can't see how 
you can read some sort of objection to Accept headers based on my 
pointing out that content negotiation implementations should pay 
attention to q values.

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

Received on Friday, 12 December 2008 15:43:24 UTC