Křištof Želechovski wrote:
If the server infers the MIME type from content and sends it over HTTP as it
should, you can have both.
Changing servers (including getting existing installs updated) is even more
painful than changing browsers, though.
It would be very nice if servers had better M
]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [whatwg] text/html for html and xhtml
William F Hammond wrote:
> Or, if that is too hard or too politically difficult,
> going forward the WG should provide a formula for the front of a
> document that asks for an xh
William F Hammond wrote:
1. Many search engines appear not to look at application/xhtml+xml.
That seems like a much simpler thing to fix in search engines than in
the specification and UAs, to be honest. I don't see this as a
compelling reason to add complexity to the parsing model.
2.
William F Hammond wrote:
Perhaps you should clearly state your definitions of "bad" and "good"
in this case? I'd also like to know, given those definitions, why
it's bad for the "bad" documents to drive out the "good", and how you
think your proposal will prevent that from happening.
"Good" an
On 17/04/2008, William F Hammond <[EMAIL PROTECTED]> wrote:
> Previously:
>
> Yes, but the point is, once a user agent begins to sniff, there's no
> rational excuse for it not to recognize compliant xhtml+(mathml|svg).
Yes there is. Live content rely on even perfectly well formed XHTML to
hav
William F Hammond wrote:
The experiment begun around 2001 of "punishing" bad
documents in application/xhtml+xml seems to have led to that mime type
not being much used.
That has more to do with the fact that it wasn't supported in browsers
used by 90+% of users for a number of years.
So use
