W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006

Re: A forms-lite straw man

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Sat, 09 Sep 2006 12:47:51 -0400
Message-ID: <4502F037.4020402@earthlink.net>
To: John Boyer <boyerj@ca.ibm.com>
CC: public-appformats@w3.org

John Boyer wrote:
>> The |version| attribute is deprecated... Haven't seen it used in the
>> wild.
> 
> 1) So?!?  That it is not in current use doesn't mean it cannot be
> reactivated in order to help control updates to the language.  If
> standard-compliant processors agree to only make features available
> based on version,[...]

   I've heard that there is already a problem with vendors claiming
support for certain feature or certain versions of a technology when
they don't support or fully support those technologies. It was a primary
argument for avoiding versioning in the WHATWG mailing list. I'd suggest
you do a search of the WHATWG mailing list for more information, as it's
been a while since I read the threads on that.

> [...] then anyone attempting to use new features will notice
> right soon that they aren't working and quickly learn to add the version
> attribute to get at the new features.

   No, actually one vendor will support the features, then web authors
with complain to the other vendors until they implement those features
in a similar way. If the browser that breaks with versioning has a
Microsoft-esque marketshare, you can forget versioning altogether.

   Besides, versions are one more pain in the gluteus maximus for web
authors to worry about. If anything, they would like a simplified
doctype, not a mandatory attribute they currently don't use.

> 2) So?!? My point is not so literal and concrete as you are reading it.
>  The specific implementation does not concern me.  What concerns me is
> proving that there exists at least one easy method to overcome the
> problems people keep raising.  Remember, obstacles are what you see when
> you take your eyes off the goal.  If you don't like the version
> attribute, then how about noting the namespace attribute?  How about
> simply using an XML reader until a problem is noted?  How about using a
> tag soup reader until a new feature is noticed?  How about you propose
> some other solution you like better now that we know that there is at
> least one solution to the problem?

   I think the better solution is to have the following:

1) New markup should gracefully degrade into HTML 4.01 when served
using "text/html", whether we're talking about "HTML5" or XHTML.

2) Authors should be able to add new features with minimal effort. For
example, if you have this...

| <label>Date: <input name="date1"></label>

...you should be able to convert the text box to a date picker by simply
adding the "date" type:

| <label>Date: <input type="date" name="date1"></label>

   Authors shouldn't have to worry about whether they remembered to
change the |version| attribute or doctype to allow the feature. It's not
reasonable to expect the triumph of diligence over convenience.

3) HTML-only browsers should be able to add support for the new markup
with only minor architectural changes (i.e. not rebuilding the
parser/renderer from the ground up to support XML).

4) An XHTML flavor of the markup should be implemented on all systems
that implement their HTML counterparts.

5) The markup should be designed in such a way that it can be added to
XForms without causing a direct conflict with existing XForms features.
As such, a new version of XForms would be created that would incorporate
the following:

 * XForms 1.x
 * XHTML 1.x Forms Module
 * Web Forms 2.0 (XHTML Module)
 * Additional refinements need to to integrate the above features.

6) Markup that dilute the theoretical purity of XForms but otherwise
cause no practical conflict within the language can be deprecated but
should not be obsoleted.

   The above scenario allows authors to start with HTML 4.01, XHTML 1.0,
HTML+WF2, XHTML+WF2 or XForms 1.x and migrate all the way to the next
generation of XForms by simply ensuring the markup is formatted for XML
and has the appropriate namespace.

>> Explain how you do efficient incremental rendering.
> 
> Already did.  The original solution I described offers the ability to
> detect what's going on as soon as the first start tag has been read.
> Explain why that *doesn't* work.

   Using the |version| attribute (or the <DOCTYPE> element, which is
probably better due to its wider use) is not necessarily a good idea,
because you have to be able to handle weird tag soup situations without
disabling features, such as a <script> element before <html>. You could
say that the browsers should just disable new features in that case, but
this really hasn't worked in the past, because it gives an advantage to
the browser that thumbs its nose at all-or-nothing error handling.

   If you always treat "text/html" as HTML, you don't have to probe
document contents at all. Besides, browsers that actually support XHTML
will support its MIME type anyways. Furthermore, the <DOCTYPE> element
is largely used to determine if you go into quirks mode and such, not
which parser you use or what elements will work.

>> You can't rely authors to accurately version content
> 
> Quoi?!? If author doesn't version content and as result doesn't access
> feature, then author sure as heck can be relied on to version content.

   Until someone comes along and makes it work without the version, then
you're screwed. If you where a browser vendor that offered technical
support, would you want to support strict versioning to be compliant
with the spec, or would you do away with it to avoid the thousands of
phone calls about why feature X doesn't work? Now consider that your
competitor may gain an advantage over you by abandoning version enforcement.

>  What evidence do you have to the contrary?  The only evidence you have
> is that previous browser makers went off and made everything work
> regardless of version number, so the version number was ineffective.
>  That's bootstrapping!

   Excuse me, but if the browser developers you speak of don't think
it's a good idea to do versioning, who's going to implement your
precious browser WITH versioning?

>> What's the point of ignoring features, esp. when the content is served
> as text/html?
> 
> Because the content type says only what kind of document is coming down
> the pipe, but HTML itself gets to define what HTML means, and if
> features are added by version then they only work when the content says
> they work.

   Doesn't that just boil down to "because we said so"? Besides, if
there's no |version| or doctype at all, are we going to forbid user
agent vendors from using the new web forms features, even if the vendor
don't even claim compliance with the new specification?

> My own evidence that versioning does indeed work across millions of
> users over 13 years would be my own forms language has undergone the
> following releases: 1.0, 1.1, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 3.0, 3.1,
> 3.2, 3.3, 4.0 (start of XML),  4.0.1, 4.1, 4.2, 4.3, 4.4, 4.5, 5.0, 5.1,
> 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, and 7.0.

   Could you be a bit more specific as to the example you're are
referencing. For instance, does the forms language you're talking about
have a large, non-technical user base like HTML has? If so, why aren't
we just using that instead of XForms?

> This is why I don't believe
> people who say it can't be done.  I prefer to believe Ian Hickson's
> favorite quote, which is just that it takes longer, which I interpret to
> mean that the processor author has to do a bit more work.

   Don't drag Ian into this. He'd probably oppose versioning if he
weren't on vacation right now.

> However,
> versioning really is the only *effective* way to cultivate a language
> over time.

   Even if that were true, you do not present a convincing argument as
to why we need to introduce version-based restrictions for WF2 feature
support. There's nothing about WF2 that requires strict feature control
due to graceful degradation. Web Forms 2.0 is an extension, and
evolutionary in nature rather than revolutionary. It should be used as a
bridge to XForms and not a carrot.

>> can't expect them to memorize what version their markup appears in
> 
> Why do you think I expect such memorization?  I don't even expect people
> to memorize the tags they're supposed to use.  They use things like ref
> manuals.  They have to create some content at a moment in time, so they
> google the bits they need, it tells them what's available by version,
> they check the version available on the processors they intend to make
> the content available to, and they go about their business.

   Except that you're wrong. A lot of people copy-paste code from other
web pages when they want to use specific features. Furthermore, if
markup is locked out in future versions, and you use the older markup
when editing a web page in a newer version and unintentionally make the
page less functional than before the edit.

> Query, how is this really different from what you would propose they do
> *without* some kind of versioning?  The content author still has to know
> whether their intended processors support the "version" of HTML they
> want to use, whether or not they have to declare the version number is
> orthogonal to this.

   No they don't. WF2 is designed to have reasonable HTML 4.01 fallback.

> Put another way, what does the 2.0 in Web Forms 2.0 mean?

   I challenge you to find anywhere in the draft where it explicitly
states that WF2 is a "new version" of HTML Web Forms. In fact, the
abstract calls it an extension, which makes the 2.0 in Web Forms 2.0
more akin to a CSS level.

   It's really irrelevant, though, because we aren't arguing about
having versions. Our disagreement is about limiting the functionality of
the user agent based on the document version.

   I just had a terrible thought: Using frames or iframes to load in
documents with different versions so you can use their respective features.

> It surely seems to mean that IE won't be supporting it any time
> soon, so the content author better have a plan B, such as not using WF2
> if the processor doesn't support it or *recognizing* that they are using
> features of a different "version" of the language by including some
> additional javascript files or what have you.

   In the rare event that web authors find the WF2 fallback unacceptable
for their use case, they can use the hasFeature method (from DOM1) in
scripting to detect support and turn on a DHTML widget or the like on
legacy user agents. (If scripting is turned off, they can't have been
able to do much in HTML 4.01 anyways, so that doesn't seem an issue.)

> The point is that *in
> some syntactic way* the author has to know the version of language from
> whence their features are coming.

   Hogwash! People make quotes from literature everyday but don't know
where those quotes come from. People still think that P. T. Barnum said
"There's a sucker born every minute". [1] Why do you think it's any
different with HTML? They'll see something, plug it in and run with it,
version be damned.

>> Better to use deprecation in later versions and leverage existing
>> structures where appropriate
> 
> Sorry, did you just say versions?

   Yes. We were talking about HTML, and it does have versions. What it
doesn't have is feature restriction based on versions.

> I don't mind deprecation, and in fact that's what we're trying to do
> with tag soup.  The effective way to deprecate stuff is to provide
> incentives for content upgrade.  Like new features.

   And if someone implements WF2 or XForm features in HTML, what can
you, me or the W3C do to stop them? Oh, wait, Opera already did that!
BAD OPERA! BAD!!! NO COOKIE FOR YOU! Mozilla, I'm watching you!...

   In all seriousness, this spec started at WHATWG, whose membership is
made up primarily of browser vendors, so I wouldn't expect infinite
patience on their part. Web Forms 2.0 is rather mature, so fundamental
changes may not be well received.

>> Conversion is a bad idea
> 
> Why?  If someone wants to write simplified syntax for their content, then
> let them do that.

   No one said they couldn't. I was referring to requiring conversion to
XHTML for compliance with "HTML5".

> But when they finally get to that point when they
> need more depth than single attributes can provide, why not have them
> run a converter so they can get a more formal model, see what their
> on-the-glass design implies, and then they can begin extending the more
> formal model because they have some idea what it means.  Their
> originating document is the Rosetta stone that helps them get started,
> but it's really gated by when they choose to enter the world of more
> sophisticated content.

   I think I see the problem here. You seem to have been talking about
development tools, whereas I thought you were referring to client user
agents. Developers are free to use whatever tools they find useful, so
long as the user agent isn't unduly burdened by them.

>> There's no benefit to implementing an "HTML5" if it's not directly
>> supported.
> 
> By whom?  IE doesn't define the full extent of the web.

   There are many HTML-only browsers. IE just has the greatest marketshare.

> If it did, then
> we should say that there's no benefit to WF2, to XForms, to PDF, etc.
> Yikes.

   First of all, WF2 can be implemented in HTML-only browsers far easier
than XForms or PDF. Secondly, WF2 is design to gracefully degrade into
HTML 4.01. (Yes, I know I'm sounding like a broken record...)

> XForms is enabled in all major web browsers through a combination of web
> technologies.

   It's implemented via plug-ins and extensions on major browsers that
exist on personal computers. I don't have XForms support installed for
any of the browsers on my home machine, nor is it even possible for me
to install support for it for my cell phone browser or for an in-game
browsers like the one in EVE Online.

> Any upgrades to HTML do require direct implementation,
> but the pool of available implementers of web technologies is much
> larger than just web browser makers. I sure hope we're not saying
> that all implementers have to go home except those who make an actual
> web browser, because my counter would be that all implementers should go
> home unless they constitute more than 50% of the browser marketshare.
> Since I don't buy the latter, I obviously don't buy the former either.

   I really don't know what your point is here. Are you suggesting that
extending HTML and XHTML at the same time will somehow undermine all
other web technologies?

>> It would make more sense to do an HTML to XHTML conversion on the
>> original document before making it available on the server.
> 
> Totally agree with you here.  It would have benefits for the author to
> begin to see what has to be done differently.  However, authors of
> content processors really are free to choose what content they are
> willing to recognize and process. They're also free to decide what data
> structures and algorithms exist in their implementations to effectively
> respond to that content. 

   Never said they couldn't. I'm not the one saying that WF2 features
should be XML-only, though, which does tell authors of content
processors what content their software can process if they want to be
compliant. Nor do I think such restrictions are enforceable. Therefore,
if we've already done the work to ensure that these features work under
HTML, there's really no point in excluding HTML from supporting them.

> They're also free to decide what data
> structures and algorithms exist in their implementations to effectively
> respond to that content.  A content processor author with an ability to
> efficienlty process XML could well consider JIT conversion of the stream
> to XML, and a content processor author who has an implementation bent
> around tag soup could well consider a reverse conversion of the XML down
> into something the processor can handle more easily.  Either way, those
> are implementation details that we don't seek to standardize, and they
> are details that are independent of deciding what features to make
> available by some sort of versioning scheme.

   Web Forms 2.0, including the HTML support, is already a WHATWG
standard, and it could be submitted to standards organizations outside
W3C, so the most the W3C can do is refuse to make it a W3C recommendation.

   Personally, I don't see the point of making the HTML web forms model
better, then limiting it to XHTML. You might as well just implement an
easier way to use XForms by recycling ideas from WF2. If you standardize
WF2 as XHTML only, all the members of the WHATWG will just implement it
for HTML anyways, and Microsoft will probably be tempted to follow their
lead due to the cost of implementing XHTML, making it a defacto standard.


[1] http://www.historybuff.com/library/refbarnum.html
Received on Saturday, 9 September 2006 16:48:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:20 GMT