[whatwg] <output> and onforminput

On Mon, 21 Jun 2004, Jim Ley wrote:
>>
>> I think you are reading way too much into "backwards compatible".
>>
>> HTML4+ECMAScript is "backwards compatible" with Lynx.
>
> Sure it is

So GMail works in Lynx?


> but HTML4 + WF2 is not - since you're over constraining things like
> datetime which mean they do not work in a non-WF2 browser without
> particularly aware users.

If a user is using Lynx, he is likely to be reasonably savvy. (Indeed, if
the user is using anything but IE, he is likely to be reasonably savvy.)

It is not difficult to explain to users that the syntax they enter must be
a particular syntax. And servers would be perfectly allowed to make
whatever allowances they want for date entry, just as they do now.

So I really don't understand the problem.


> Consider datetime input, it requires the client to send back the time in
> UTC, so a non WF2 UA can't do this unless the user inputs it in UTC.

A non-WF2 UA is (obviously) not bound by the requirements in the WF2 spec.
Nothing stops the user from entering whatever he wants, and the server
from handling it as it wants, if it wants to support non-WF2 clients.


>> You said that you half-agreed with the backwards-compatibility
>> argument presented at the recent workshop; which part did you _not_
>> agree with?
>
> No, I didn't say I argeed to that, I said I voted for the work to
> improve and extend HTML 4 within the W3, I support graceful degradation,
> but very little of the WF2 content does gracefully degrade other than on
> a purely visual sense, the interaction environment with the server
> doesn't degrade gracefully.

It would be helpful if you could send specific comments on the areas that
still do not gracefully degrade, along, ideally, with an example of how
they could be made to degrade in a way that you would consider acceptable.


>> What do you mean by backwards compatibility, in the context of new
>> specifications like this?
>
> The content works in existing UA's - I do not believe the WF2 spec meets
> that goals in all but a minor part of it.

We seem to agree on the definition but disagree on whether the spec hits
that definition -- maybe we have different meanings of "work".

I consider <input type="number"> (for example) to gracefully degrade, even
though on a non-WF2 UA, nothing stops the user from submitting non-numeric
data. If the server is willing to deal with non-WF2 UAs, then it can
perform error reporting, just like servers currently do even though their
client-side scripting did validation as well.


> The whole spec seems to be missing both use-cases (what is the use case
> of a UTC datetime control?) and realistic descriptions of how it
> degrade, publish some WF2 applications, show us how they degrade in
> todays browsers!

I assure you use cases were the basis of every feature in the spec.
(Indeed it is one of the key principles this work is being done under, see
the Opera/Mozilla position paper). The use case for the datetime control
is any system that needs to have an exact time, e.g. a calendar
application, as opposed to a local time, as in airline booking.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 24 June 2004 05:31:44 UTC