[whatwg] Re: <output> and onforminput

[Malcolm Rowe]

Jim Ley writes:
>> [local-time datetime stuff is already in another message - snipped]

>> 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.

Maybe I didn't explain very well (or I don't understand what you're saying). 
If you already use script to validate the date entered is valid, then you 
must validate on the server, because people run with scripting disabled. 

Therefore, if you were to use a WF2 control that restricted the submission 
to valid dates only, you must still validate on the server, because people 
might use non-WF2 UA's. 

Indeed, you can still use client-side script to validate/change/whatever the 
date format for non-WF2 UA's, it's just that people with WF2 UA's will get a 
'richer' control. 

In *both cases* (restrict via script / restrict via declaration), a non-WF2 
non-script UA will have to enter data in a restricted format, or, 
alternatively, the server might attempt to parse different formats; either 
way, the server must be capable of dealing with it. 

(Note that a WF2 client doesn't have to force the user to enter dates in any 
particular format, it just has to use a particular submission format.) 

>> 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.

Really? where? IE6 is a target for 'extra' compatibiity libraries, sure, and 
that's due to its market share, but WF2 is explicitly designed to work in 
*all* legacy clients, not just IE6. 

>> 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?

> the changes to the action semantics,
I believe that we're just documenting existing practice here, and clarifying 
behaviour in error cases (where there's no consistent implementation 
anyway); are you aware of anything particularly that's changing? 

> moving form elements outside of form parent groups,
Again, this is something that existing clients already have to deal with. If 
you don't do it, you're not 'IE bug-compatible', and websites break. So, no 
change here, at least for those UA's that want to work on the tag-soup 
real-world internet. 

> the user problems I've highlighted with datetime etc.
Ok. That's not a backward-compatibility issue though - it's a usability 
issue that you can easiliy have with existing HTML4 forms. 

> Filling select elements, replace=* (there's no mechanism for the
> server to know a WF2 client is making the request)
Why does the server care? 

Regards,
Malcolm