Re: Content Type

Allan Beaufour:
> 
> On 3/21/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> > > I was wondering if XForms had a Content-Type associated to it
> > > such as application/xforms+xml. I have not seen any on the
> > > IANA website nor anywhere else. Please forgive me if I
> > > haven't looked carefully enough.
> >
> > As Victor said earlier, it doesn't have such a type. What we need is
> > actually some kind of 'sub-type' mechanism that lets us know that the
> > browser has a plug-in installed--there are a number of suggestions on how to
> > solve this, but nothing has been firmed up yet.
> 
> Yeah, we've also discussed it for some time. Adding a user-agent
> identifier is not really "the right thing" to do, because you need to
> know what combination of languages that the client supports, i.e.
> XForms+XHTML, XForms+SVG, XForms+XHTML+SVG, etc. etc... This is a task
> for the CDF working group
> (the Firefox bug for it is here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=279729)

2 cents:

Isn't it time for user agents to start reporting more fine grained which
standards they support? The HTTP Accept header doesn't provide enough
information to know whether a document will be understood at all, and
can lead to quite a few hacks, specially on sites using cutting edge
technology, such as SVG or AJAX.

For an example, take a look at the correspondence between the Firefox
1.5.0.1 Accept header
(text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5)
and the support level reported at
http://www.webdevout.net/browser_support.php or
http://en.wikipedia.org/wiki/Comparison_of_web_browsers.

Say that I want to serve a page with some SVG, MathML, CSS2/3, and AJAX
functionality. Each of these requires different hacks to ensure that
non-compliant browsers don't barf on the contents. For SVG and MathML, I
can use CSS to put the advanced contents above the replacement images,
or use e.g. SVG <desc> to provide replacement text. Both methods
increase the amount of contents sent to the user agent, and are not
really accessible - Non-visual browsers get the same information twice.

For CSS, countless hacks have been devised to make sure sites display
the same in different browsers. So the user agent always receives more
information than it needs.

AJAX needs to check for JavaScript support, then XMLHttpRequest support,
and then must use typeof to switch between JS methods. This can easily
triple the length of a script.

What if browsers could negotiate support with the server using e.g.
namespace URIs, where these would reference either a standard, part of
it, or some pre-defined support level? Poof, SVG 1.1 Tiny 95% supported,
CSS 3 10% supported, DOM level 2 80% supported, etc..

Obviously, the Accept header would be much longer, but the contents
received could be reduced significantly. Also, I believe it would be
easier for developers to use only Accept header switching than learning
all the hacks necessary for modern web development.

I don't really know if this is possible, but maybe this kind of Accept
header could be separated into a special HTTP reply. This would contain
the URIs of the potential contents, and the user agent would send a new
HTTP GET request with the modified Accept header, reporting the support
levels.

-- 
Victor Engmark
All generalizations are wrong.

Received on Wednesday, 22 March 2006 10:09:51 UTC