RE: XForms and multi-line text entry

I agree. Isn't this kind of thing defined by the host environment? If processors are visually rendering on OS X, for example, then would it not make sense to follow OS X conventions, and so on. I'm not sure that it would be useful or appropriate though for all XForms processors to behave in the same way across all deployment platforms and host languages, as that would in itself create wider inconsistencies.

All the best

Mark

 
The information in this email is sent in confidence for the addressee only and may be legally privileged.  Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission.  If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.

Origo Services Ltd accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or the contents. 

> -----Original Message-----
> From: Daniel Fowler [mailto:daniel.fowler@focus-solutions.co.uk]
> Sent: 17 July 2003 19:07
> To: www-forms@w3.org
> Subject: RE: XForms and multi-line text entry
> 
> 
> 
> It would also be good to get consistency of keystrokes 
> between different
> XForms processors.
> 
> For example, in one processor the tab key moves you forward 
> through the
> controls. In another the tab key does the same until you 
> enter a textarea
> control, at which point it enters tabs in the textarea and 
> you need to press
> cntrl-tab to move forward again. (In the first processor it 
> is not possible
> to enter tabs in the text area control.)
> 
> Another example. In one processor the input control updates 
> the model when
> the user tabs away. In another processor the same happens but 
> you can also
> update the model my pressing the enter key and remain within 
> the control.
> 
> It would be good for usability to define a base behaviour for keyboard
> actions. If only to defined consistent keyboard handling for 
> accessiblity
> considerations.
> 
> DAN
> Daniel Fowler
> Solutions Architect
> daniel.fowler@focus-solutions.co.uk
> 
> 
> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: 16 July 2003 09:28
> To: steven@w3.org
> Cc: www-forms@w3.org
> Subject: XForms and multi-line text entry
> 
> 
> 
> Is there anything that can be done to improve the usability of
> multi-line text entry for XForms?
> 
> When typing into a multi-line text field, it is hard for users to
> know what the significance the Enter key has. In some cases the
> assumption is like a word processor, Enter is used to start a new
> paragraph and text will be wrapped to fit the appropriate margins.
> On other cases, the text will be kept as typed and it is important
> to use the Enter key regularly to avoid very long lines that run
> straight off the right handside of the page/window.
> 
> The text input controls don't give you any visual clues as to
> whether a line break was due to you hitting the Enter key or the
> result of a line wrapping operation by the input control.
> 
> If you are used to regularly hitting the Enter key to limit line
> length, and the forms processor is using the word processor
> model, the you are unknowlingly splitting your text up into lots
> of paragraphs. If the forms processor keeps the text as typed,
> you are later faced with very long lines and being stuck with
> lots of horizontal scrolling.
> 
> My feeling is that the text input control needs to know and
> implement the appropriate assumption. This is beyond what can
> be expressed with XML Schema, and is more than styling, and as
> such seems like something that XForms should be able to express
> as an XForms annotation.
> 
> My suggestion would be to allow for the following cases:
> 
> 
> a) Whitespace characters are passed to the forms processor
>    exactly as entered, leaving the semantics of whitespace
>    entirely up to the forms processor, with all the usability
>    problems that entails.
> 
> b) Enter starts a new paragraph and text will be wrapped within
>    paragraphs as needed for display purposes. (Word processor model)
> 
> c) What you see is what you get - the Enter key inserts a hard
>    line break, as does wrapping by the text input control.
> 
> d) Like (c) except auto-wrapping is off, so that all line breaks
>    must be made explicit by hitting the Enter key
> 
> I have a further suggestion, which is to allow application authors
> the ability to control whether a multiline text input control grows
> in height to accomodate the text it contains, or whether it clips
> and offers some means of scrolling through its contents.
> 
> I believe that this is a matter of applying the appropriate CSS
> property, and will involve some coordination with the CSS working
> group.
> 
> Text input areas that grow as you type are a nice feature
> since users are in control of what they see and aren't subject
> to the imposition by authors of a fixed display area that
> limits the number of lines visible. In other words, users can
> glance up and see what they typed without being required to
> scroll through the text within the text input control.
> 
>  Dave Raggett <dsr@w3.org>  W3C lead for voice and multimodal.
>  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
>

Received on Friday, 18 July 2003 03:52:59 UTC