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,
Marcos

2008/12/10 Laurens Holst <lholst@students.cs.uu.nl>:
> 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
>
>



-- 
Marcos Caceres
http://datadriven.com.au

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