[whatwg] Re: <output> and onforminput

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'