T.V Raman | 1 Sep 01:17 2006
Picon

RE: XHTML and MIME (was: IBM Position Statement on XForms and Web Forms 2.0)


Doug, You make an interesting point. 

Personally, I believe that the decision to mandate that xml
content types be served as application/xml+xhtml was the key
mistake that happened circa 2000  --- I still distinctly remember
feeling very unhappy about this at the Amsterdam WWW conference.

Background/Run-Up To The Above:

At the time all the Web companies -- including browser vendors,
authoring tool vendors, organizations representing Web Developers
all came together in 1998 at the "Future Of HTML" Workshop 
http://www.w3.org/MarkUp/future/

Here is what the world looked like:

A)   The browser wars were all but over bar the shouting

B)   Everyone had suffered sufficient tag-soup pain to last
     several lifetimes
C)   Everyone in the Web community had suffered from the browsers
     *exclusively* dictating what Web pages worked --- I remember
     this as the "a new tag every Monday" phenomenon. No one
     could create, develop or deploy content reliably -- leave
     alone deploy tools to create, manage or deploy Web content.

So then, the above was the background at the time we all
collectively resolved to close off HTML4 development, and move to
a cleaner, well-formed world.
(Continue reading)

L. David Baron | 1 Sep 01:36 2006

Re: XHTML and MIME (was: IBM Position Statement on XForms and Web Forms 2.0)

On Thursday 2006-08-31 18:27 -0400, Doug Schepers wrote:
> There seems to be a major divide between people who believe that XHTML
> cannot or should not be used on the Web (largely because IE does not yet
> understand it), and those that believe it can and should.
[...]
> Ian Hickson, the champion of the first camp, has outlined his position [1]
> in a paper that seems to be the seminal claim for the notion that XHTML
> cannot be served with the "text/html" MIME Type.  This paper is often cited,

I think this summary tries to condense three separate issues into one:

1. Should XHTML be used on the Web?

2. Should authors send XHTML content under the text/html MIME type?

3. When authors send XHTML content under the text/html MIME type,
   should browsers treat it differently from other text/html?

Trying to discuss these three issues as a single issue will just lead to
confusion and misunderstanding.  (They are related, however.)

The document of Ian Hickson's that you cite [1] is a position on
question #2.

The HTML working group answered question #3 in [2] (answer: no),
although it was unanswered in the original XHTML1 recommendation.  I
think this was a mistake (although I didn't feel as strongly about it at
the time).

-David
(Continue reading)

Lachlan Hunt | 1 Sep 01:49 2006
Picon

Re: XHTML and MIME


T.V Raman wrote:
> Personally, I believe that the decision to mandate that xml
> content types be served as application/xml+xhtml was the key
> mistake that happened circa 2000

XML MIME types are */*+xml. i.e. "application/xhtml+xml"

> Sadly, this happened right around the time the decision to place
> newer XML-based content-types  under mime-type application/xml+*
> happened [...]

Your brief history failed to explain *why* XML MIME types are a bad idea.

--

-- 
Lachlan Hunt
http://lachy.id.au/

Lachlan Hunt | 1 Sep 01:53 2006
Picon

Re: XHTML and MIME


L. David Baron wrote:
> The HTML working group answered question #3 in [2] (answer: no),
> although it was unanswered in the original XHTML1 recommendation.  I
> think this was a mistake (although I didn't feel as strongly about it at
> the time).

Do you mean it was a mistake that the WG said no to content sniffing or 
a mistake that it wasn't stated in XHTML 1.0?

--

-- 
Lachlan Hunt
http://lachy.id.au/

L. David Baron | 1 Sep 02:02 2006

Re: XHTML and MIME

On Friday 2006-09-01 09:53 +1000, Lachlan Hunt wrote:
> L. David Baron wrote:
> >The HTML working group answered question #3 in [2] (answer: no),
> >although it was unanswered in the original XHTML1 recommendation.  I
> >think this was a mistake (although I didn't feel as strongly about it at
> >the time).
> 
> Do you mean it was a mistake that the WG said no to content sniffing or 
> a mistake that it wasn't stated in XHTML 1.0?

I mean it was a mistake that the WG said no to content sniffing.  (I
would have preferred to do it based on the presence of the XML
declaration, "<?xml ... ?>".)

In particular, content sniffing would have allowed migration to XHTML
without waiting for the vast majority of browsers to support it.

I'm also unhappy about the other steps that the HTML working group has
taken to reduce ease of migration to XHTML:  for example, by insisting
that other specifications that have special rules for HTML (such as
CSS's rules for handling backgrounds on the body element) make them not
apply to XHTML.

-David

--

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation
Lachlan Hunt | 1 Sep 04:15 2006
Picon

Re: IBM Position Statement on XForms and Web Forms 2.0


Mark Birbeck wrote:
> but there are lots of things you can do with a C++ plug-in that you 
> cannot do efficiently in script. (If there weren't, why would you bother
> implementing WF 2.0 natively?)

Of course.  Any JS implementation is going to be limited and a plugin or 
native support in the browser is obviously going to be superior.

> [...] the different XForms implementations reflect this--you can go 
> from a server-hosted, zero-install solution like Orbeon or Chiba,

As far as I can tell from my brief look at those two today, they convert 
XForms on the server side to HTML 4 forms on the front end.  Is that 
correct?  If so, that fits the model described in WF2.

http://www.whatwg.org/specs/web-forms/current-work/#r-to-xforms

> FormsFaces

For that JS implementation to function in IE, it requires serving as 
text/html, which (as I've already said) is unacceptable.

> and facileXForms in between.

I couldn't find that one.  I found "FacileForms" for Mambo and Joomla, 
but that didn't appear to have anything to do with XForms.

>> XForms is also requried to be used within an XML document served with an
>> XML MIME type, such as application/xhtml+xml...
(Continue reading)

Lachlan Hunt | 1 Sep 05:48 2006
Picon

Re: IBM Position Statement on XForms and Web Forms 2.0


John Boyer wrote:
> I believe you are reading some specs far too rigidly.  Please see the 
> first line of Appendix C of XHTML 1, which says it is informative (as 
> opposed to normative).

I'm aware of that.  But XHTML 1.0, Section 5.1 (which is normative) 
referrs to the Appendix C guidelines as a requirement for labelling the 
documents as text/html.

The XHTML Media Types note (yes, I know it's only informative) states in 
section 3.1 [1]:

   "In particular, 'text/html' is NOT suitable for XHTML Family document
    types that adds elements and attributes from foreign namespaces, such
    as XHTML+MathML"

In section 3.5 (the summary table) the example of XHTML+MathML states 
that it *should not* be served as text/html.  I know that's not quite 
the same as *must not*, but XHTML 1.0, section 5.1 explicitly states 
that text/html may only be used for documents that are "*compatible with 
most HTML browsers*".  MathML or, in this case, XForms is not really 
compatible with HTML UAs, because they require XML processing.

> Second, XHTML is an XML application, which supports namespaces, so why 
> would the guidelines cease to apply because a particular feature of XML is 
> used in the XHTML?

It's because the Appendix C guidelines don't apply to XForms, only to 
XHTML that is compatible with HTML browsers.
(Continue reading)

Doug Schepers | 1 Sep 07:31 2006

RE: XHTML and MIME (was: IBM Position Statement on XForms and Web Forms 2.0)


Hi, David-

Thanks for your reply.

L. David Baron wrote:
| 
| I think this summary tries to condense three separate issues into one:
| 
| 1. Should XHTML be used on the Web?
| 
| 2. Should authors send XHTML content under the text/html MIME type?
| 
| 3. When authors send XHTML content under the text/html MIME type,
|    should browsers treat it differently from other text/html?
| 
| Trying to discuss these three issues as a single issue will 
| just lead to
| confusion and misunderstanding.  (They are related, however.)
|
| The document of Ian Hickson's that you cite [1] is a position on
| question #2.

I intended the summary to encapsulate the broad range of ideas that each
"camp" holds, though I'm certain there are people who do not fall neatly
into my summary.

I'm happy to break the discussion down into whatever level of granularity
will help us reach a position from which we can move forward.  As you say,
though, the issues are closely related, in that each is predicated on the
(Continue reading)

Doug Schepers | 1 Sep 07:40 2006

RE: IBM Position Statement on XForms and Web Forms 2.0


Hi, Lachlan-

Lachlan Hunt wrote:
| 
| For that JS implementation to function in IE, it requires serving as 
| text/html, which (as I've already said) is unacceptable.

You treat this argument, which informs many of your subsequent claims, as
axiomatic.  It is not.  It is, in fact, merely a particular interpretation
of the range of options out there, and a controversial one at that.

I submit that this particular "problem" is not insoluable, given the
application of a little flexibility and imagination on both sides.

Regards-
Doug

Francisco Monteiro | 1 Sep 08:06 2006
Picon

RE: IBM Position Statement on XForms and Web Forms 2.0

Lachlan,

> and facileXForms in between.

> I couldn't find that one.  I found "FacileForms" for Mambo and Joomla, but
that didn't appear to have anything to do with XForms.

I promise you that facileXForms is not "Mambo Jambo" neither is it Joomla,
are these ingredients in a witches stew?

See some of my previous posts about facileXForms.
Francisco
facileXForms - Ajax at heart
Attachment (smime.p7s): application/x-pkcs7-signature, 4337 bytes

Gmane