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

Hi Laurens,
As we no longer require user agents that conform the the packaging
spec to support any media types, I have added xhtml as a default start
file (extensions are .xhtml and .xht). This will be in the spec when I
next check the spec in.

Kind regards,

2008/12/10 Laurens Holst <>:
> 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]
> [2]
> --
> 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: Backbase employee;

Marcos Caceres

Received on Wednesday, 25 February 2009 15:24:27 UTC