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

Hi Laurens,

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).
>

Please read the spec for a definition of a widget user agent (widget engine).

> 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.
>

This encourages fragmentation. We don't want developers developing in
XHTML at all if those widgets are not going to work interoperably on
HTML-only widget engines (and yes, those exists! a reference
implementation of this specification is being developed on pocket IE).
We don't forbid xhtml (hence the content element's type attribute.)

>> 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.
>

I'm not going to be drawn into citations war about this. This isn't
about that.

> 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.
>

And I quote, " HTML 4 is an SGML application conforming to
International Standard ISO
   8879 -- Standard Generalized Markup Language [ISO8879]."

The HTML4.01 spec says it's so. Browsers didn't follow the spec. By
specification, HTML4.01 *is* SGML. If you deny this fact, then your
notion of HTML has not been formally defined anywhere.

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

I'm not sure what "this" is. I also don't particularly care about what
Hixie's position is on things. I'm capable of drawing my own
conclusions from whatever evidence is available. Hixie's document,
although advocating a position, formulates are logical argument backed
by testable/verifiable evidence.

>> 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?
>

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.
>

If it's purely optional, it's not necessary to have it in the Widget
spec. The mapping to a file extension It's already defined here:
http://www.rfc-editor.org/rfc/rfc3236.txt

>> 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 appreciate you insulting me or other members of the working
group by implying we are ignorant.
I'm not hiding behind anything: as editor, my role is to represent the
interests of members and the public in the spec. Also, I never said
anything about good/bad aspects of HTML or XML.

> 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.
>

Why should XHTML get preferential treatment? By that logic I should
also add RDF or whatever other obscure implemented specification
supported by browsers.

> 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.
>

I don't have a personal preference (I think they both suck). When I
worked as a proffesional Web developer, I always happily coded
everything in XHTML strict (and served it correctly to browsers that
support it). The Widgets specs are all written and served as XHTML by
choice.

We don't support full HTML5 (only some aspects of it in the API). We
mandate HTML4.01 support.

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

Received on Wednesday, 10 December 2008 14:50:58 UTC