- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 24 Jun 2004 17:09:46 +0000 (UTC)
On Thu, 24 Jun 2004, Jim Ley wrote: > On Tue, 22 Jun 2004 10:55:41 +0100, Malcolm Rowe wrote: >> >> How is a WF2 <input type=datetime> control any different to a HTML4 page >> containing a simple input control and a script that verifies that the date >> is in a particular formant? > > It's never used (I'll ask for about the 10th time for a use case for > datetime please) Search for messages sent before: <input type="datetime"> > I'm not sure even I'm happy that I could usefully request a flight that > landed for my morning meeting in Fiji using a WF2 datetime control in a > legacy client, and I'm reasonably happy with timezones and what UTC is. Airline ticket bookings are not an expected use case of datetime control. Their time picker widgets are much vaguer, and, as you have mentioned several times, work based on the time at the airport on the day of the flight, not based on a specific world-wide-defined time. > I just don't think your average user is going to be able to do it, and I > don't think your average developer is going to be willing to use the > control for all non-UTC use (which means it'll be great for the folks in > casablanca, but not much else) For non-WF2 cases, the server would have to do server-side checking of the input anyway, as with time inputs today, so that is no big deal, the server can simply accept whatever format it wants in addition to the WF2 format. For WF2 cases, the UI is expected to be in the UA's local time zone. >> If you agree that HTML4+ECMAScript degrades, then HTML4+WF2 degrades in >> a similar fashion. In both cases, the server has to accept 'invalid' >> data (either from a non-scripting or non-WF2 client, respectively), and >> deal with it (presumably by returning an error page). > > If you use ES to change the format of the submission and reject entries > not in that format, then it doesn't degrade, this is what WF2 is likely > to do, since we cannot know if the WF2 transformations/checks have been > applied on the server. Equally, we're asking the user to dramatically > constrain what they enter. There is no reason the JS would have to constrain the value as you describe. >> I personally believe that Web Forms 2 must work in lynx. > > the WHATWG have stated this is not a goal though, IE6 was the only goal > for backwards compatibility. It depends on what you mean by "work" -- I'm not expecting that if you say <input type="range"> you'll get a trackbar in Lynx 2.8. But yes, WF2 should have a clear graceful-degradation story. In the case of type="range", the story is that it will degrade to a text input, and the user can just enter a number. >> The repetition model is the only part of the spec that I'm aware of >> that is completely unusable if you have a non-WF2 non-DOM-supporting >> client. Are you aware of any others? Actually, the repetition model can be made to work in Lynx as well using some server-side support, I'll set up a demo to show how. > the changes to the action semantics Do you mean the addition of "action" on buttons? (In which case it does gracefully degrade -- it just uses the action on the form, which can in fact be used to let a WF2 client use one server and a legacy client use one that will do different fixups.) Or do you mean the "5.6. Submitting the encoded form data set" section? (In which case those aren't changes, they are descriptions of the semantics that have up to now either been undefined or poorly described. For example, submission to data: is completely undefined right now. WF2 doesn't make the situation worse by defining it.) > moving form elements outside of form parent groups Yes, this is indeed non-backwards-compatible -- except that it isn't required, you can still use form containers if you like. This feature is likely to not be used for some time by Web authors, at least while non-WF2 UAs are widespread. Web Application developers often are happy to target only the very latest browsers, though (e.g. GMail doesn't even support Opera right now), and for those developers, this is a long-desired feature. > the user problems I've highlighted with datetime etc. No real problem here, as explained above. > Filling select elements This degrades well, it just ends up using what is defined in the <select>. As with form="", or for that matter XmlHttpRequest, or CSS, or DOM3 Core, this is a new feature which authors are not required to use but which they can use when they are targetting new UAs. (It's quite common to do things like "if the UA supports the new thing, do the new thing, else do the old thing which isn't as good but still works".) > replace=* (there's no mechanism for the server to know a WF2 client is > making the request) Using the action="" attribute on the button, you can easily have two scripts on the server, one which handles the legacy client requests and one which handles the WF2 requests. > and more, that's just from a quick scan Well, none of those you listed seem to actually have degradation problems. > it's difficult to track the document when it changes so frequently, and > I find myself having to read from scratch again to see if what I > remember is still in there. I hope to publish a stable draft this weekend, which should help with this. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 24 June 2004 10:09:46 UTC