Re: A forms-lite straw man

John Boyer wrote:
> So, let's say you receive some text/html, and you read the very first
> tag of it and find that
> 
> 1) the html tag is in the XHTML namespace, and it has a version
> attribute of version="1.2"
> 
> 2) the html tag is in any other namespace, and it has a version
> attribute of version="5"

   The |version| attribute is deprecated in HTML 4.01. I'm not sure I've
ever even seen it used in the wild.

> If these conditions are met, then you just received content that is
> new-style HTML new goodies are at your disposal. If HTML 5, run
> converter to get XHTML 1.2, at which point the complaint against using
> the XForms conceptual model runs out of steam.

   Explain to me how you do efficient incremental rendering and document
conversion at the same time. For that matter, do you honestly expect
user agent vendors to reengineer their HTML support to be little more
than a JIT XHTML converter?

   Furthermore, why can't we use an XHTML 1.1 module for web forms
support instead of creating a new XHTML 1.2?

> If neither of the above conditions are met, then you have HTML 4, so run
> only your old code (ignore tags corresponding to the new features).  

   What's the point in ignoring the features in HTML, especially if the
document has an HTML doctype and is served as "text/html"???

> It should be clear from this that you don't break the old forms.  It
> should also be clear that the issue of old forms is therefore orthogonal
> to the first issue described in this mail involving the interpretation
> of additional attributes on elements like the xforms 'input'.  The
> additional attributes are being discussed to help ease the authoring
> burden of migrating up to new-style HTML, so that there is less work to
> do to get the new features.

   You can't rely on the author to accurately version content, nor can
you expect them to memorize what markup applies to which version. Better
to use deprecation in later versions and leverage existing structures
where appropriate. Conversion, however, is a bad idea. There's no
benefit to implementing an "HTML5" if it's not directly supported. It
would make more sense to do an HTML to XHTML conversion on the original
document before making it available on the server.

Received on Thursday, 7 September 2006 15:24:24 UTC