[whatwg] Comments to Web Forms 2.0 downloaded 2004-09-18 (HTML email)

[Mattias Waldau]

 >>>> flame start

I do not really know how to respond to this!

How can you say that "I don't read HTML mail.". A lot of other people do 
and once email programs get their security act together, probably 
everyone will. And if someone should work for this, it should be you, Ian!

All I want is to be able to send a receipt that looks exactly like the 
webpage, and I cannot see why that should be forbidden.

And how can you say "This is poor UI." This is a religious statement and 
you should not be the judge on design principles of web forms. If you 
really think that, you should remove the readonly property for ordinary 
text boxes too.

<<<< flame end

You should look at your design principles for the standard. The standard 
should be as simple as possible. The number of exceptions should be low. 
Having readonly everywhere is much simpler than having it everywhere 
except .....

-- Mattias

Ian Hickson wrote:
>>ALL CONTROLS THAT SUPPORT DISABLED SHOULD SUPPORT READONLY (MAJOR)
>>
>>Readonly checkboxes, drop-down menus, buttons etc are needed if you want 
>>to be able to present the user with a receipt that looks exactly like 
>>the webpage he/she filled in. For an example see 
>>http://www.exceleverywhere.com/test/webforms2/webforms2.htm, where you 
>>get a receipt after pressing submit. Normally this webpage would be 
>>emailed to you. Note that the webpage is stripped from all logic, the 
>>QTY-field is readonly, however, we cannot prevent the user from 
>>checking/unchecking the Express Shipping checkbox.
> 
> 
> This is poor UI.
> 
> Text controls are the only controls that have an understandable 
> manipulable-but-not-editable state. If any other control, such as a 
> checkbox, looked available but wasn't changeable, that would be a nasty 
> black eye to someone's mental model of how that kind of control worked.
> 
> It would be like trying to use a lightswitch that someone had secretly 
> disassembled, glued stuck from the inside, and reassembled. But making 
> such a control look unavailable would imply that it wasn't *relevant*, 
> which wouldn't be true either.
> 
> If I was designing such a Web app, I'd use words like "yes" and "no" for 
> receipts, rather than checkboxes or pictures of checkboxes. That'd (1) 
> avoid the last problem above, (2) be more legally unambiguous, and (3) be 
> easier to convey by phone, e-mail etc. And having your receipt look too 
> much like the original form is a recipe for confusion anyway.
> 
> This is the accepted way of doing this in native interfaces as well, for 
> example the in "Summary" pane in OS X's Print dialog, which displays all 
> the current settings together for posterity/diagnostics using "yes" and 
> "no", not read-only widgets.
> 
> For prettier results you could use Unicode characters like U+2611 or 
> U+2714.
> 
> (With apologies to mpt, who originally wrote most of the above.)
> 
> 
> 
>>Workarounds and why they are not good enough:
>>
>> 1. Use JavaScript to restore the old value. This solution will not 
>>    work when sent as email, since all email readers block JavaScript
>>
>> 2. Using images for checkboxes etc in the receipt. Problem: Where 
>>    should the images be stored? Should they be part of the emailed?
> 
> 
> I don't read HTML mail. What would you do in a plain text e-mail? You 
> would just write "yes", or "no", or similar. Do that for the receipt too.
> 
> 
>