W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [widgets] Content-type sniffing and file extension to MIME mapping

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Wed, 10 Dec 2008 13:32:25 +0100
Message-ID: <493FB6D9.4070607@students.cs.uu.nl>
To: Marcos Caceres <marcosscaceres@gmail.com>
CC: Jonas Sicking <jonas@sicking.cc>, Simon Pieters <simonp@opera.com>, public-webapps <public-webapps@w3.org>
Marcos Caceres schreef:
> I'm not sure if any widget engines support application/xhtml+xml.

I do not know your definition of ‘widget engine’, but Opera, Safari, 
Firefox all support application/xhtml+xml (and Prince XML too, but I 
don’t suppose that would be used for widgets :)). And last I checked, 
Internet Explorer doesn’t implement this specification anyway (neither 
do the other browsers, for that matter).

Also, I am *not* requesting that implementors of this specification be 
required to support application/xhtml+xml, I am merely requesting that 
the .xhtml to application/xhtml+xml mapping is predefined, so that 
browsers which optionally *do* support it can be served content without 
having to explicitly create a MIME type mapping file.

> I think just adding it because it's a rec is not a valid argument. As
> Hixie argued, it may be supported by some UA's but it's not well
> understood by developers [1].

That document talks about sending XHTML as text/html, not XHTML in general.

Also, it is the opinion of one person, one that I can only partially 
agree with. For example, one of the argument is based on the premise 
that HTML4 is SGML, something which we all know is not true.

Also, actually HTML5 does support exactly this (even though Hixie 
doesn’t like it, last I heard).

> Implementation of HTML5 is well underway
> in many browsers, which supersedes XHTML in lots of ways.

XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 
does not supersede XHTML, it integrates it [1][2]. The HTML5 
specification defines the application/xhtml+xml MIME type. In fact, the 
specification’s subtitle is “A vocabulary and associated APIs for HTML 
and XHTML”. You are aware of this, right?

> I think just
> mandating support for text/html is sufficient for widgets. Adding
> application/xhtml+xml just adds more baggage to widgets and no
> implementer has requested its support.
>   

I might as well just repeat myself (again): I am not requesting that 
XHTML support be added as a requirement for widget engines. I am just 
requesting that the mapping be predefined.

> However, if implementers request it, then we will consider adding it.
>   

It would be good if the people deciding on this had an informed opinion, 
instead of making assumptions and just following the ‘HTML good, XML 
bad’ mantra that seems to be popular among certain groups lately, and 
not hide behind statements like ‘if implementors request it’.

I don’t understand the resistance against adding a MIME type mapping for 
a well-known and supported standard. As I explained before, adding a 
MIME type mapping does not actually mandate support for that MIME type 
in any way, if it does not support it the browser can respond as it 
normally would when being served application/xhtml+xml by an HTTP server.

As I said before, I hope you are not using this specification to 
perpetuate your personal preference for text/html. HTML5 supports both 
XML and HTML serialisations, and the Widgets specification should not do 
otherwise.

~Laurens

[1] 
http://dev.w3.org/html5/spec/Overview.html#relationship-to-html-4.01-and-dom2-html
[2] http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml

-- 
Note: New email address! Please update your address book.

~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, student, university of Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com



Received on Wednesday, 10 December 2008 12:32:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT