[whatwg] web-apps: API for text field selections is lacking

[Krzysztof Żelechowski]

Dnia 31-10-2007, śro o godzinie 17:56 +0200, Mikko Rantalainen
napisał(a):
> The section
> 
> 5.6.2. APIs for the text field selections
> http://www.whatwg.org/specs/web-apps/current-work/#textFieldSelection
> 
> defines attributes selectionStart and selectionEnd and method
> setSelectionRange().
> 
> These features are enough to identify the selected data and possibly
> modify the contents of text field by scripting so that the modification
> is affected by selected region.
> 
> There're some problems, though. I represent the following use case:
> 
> A page contains a textarea. Author adds an additional button for adding
> a pair of parenthesis around the selected text. The javascript code for
> this feature (given that "e" is the text field element) is
> 
> e.value = e.value.substr(0,e.selectionStart) + "(" +
> e.value.substr(e.selectionStart,e.selectionEnd) + ")" +
> e.value.substr(e.selectionEnd);
> 
> The problems with the above code:
> 
> 1) From the UA view, the entire contents of the field has been replaced
> with a new value and therefore the undo feature of the field cannot
> represent the fact that the script only added character "(" before the
> selection and character ")" after the selection. A method to update only
> the selected part of the value would be needed to correctly describe the
> real change to the value to the UA.

There is no behavioural difference between removing just the parentheses
and reverting to the previous content: the result is the same.

> 
> 2) There's no good way to set the selection because if the scripts calls
>  setSelectionRange() the UA "must set the selection of the text field"
> but it is not required to modify the focus or scrolled part of the text
> field in any way. In addition, there's no way to query the scroll
> position of the selection so the script cannot work around this issue
> either. As a result, setSelectionRange() may be used to set the
> selection but the selected selection may end up being out of the view
> from the user point of view. As textarea element may have soft wrapping
> enabled, the script has no way to even compute the correct line number
> for the selection start.
> 
> For the issue 1) I suggest adding a new method
> 	replaceSelectionText(in string selection_value)
> which replaces the section of field's value between offsets
> selectionStart and selectionEnd with the string selection_value. This
> replacement should not destroy the text field's undo history - instead
> it should be treated similarly to paste (text) operation.

Because of the platform widgets API limitations, the user agent would
have to go through the the same procedure you quoted anyway (or
re-implement platform widgets).  There is no way to replace a part in
the native text box.

> 
> For the issue 2) I suggest changing the behavior of setSelectionRange()
> to require that the selection must be made visible to the user. Perhaps
> something along the lines "UA must scroll the text field so that the
> start of the selection is visible." 

I do not feel like I would like that.

> As an alternative, a method such as
> void focusSelection() could be added so that the script may hint the UA
> that the selection should be made visible after the script has called
> setSelectionRange() and replaceSelectionText() multiple times (so that
> these actions do not repeatedly scroll the text field's viewport).
> 

Rather "reveal selection", if you please.  There is some correlation
between focus and visibility but they are not tightly coupled.

Best regards,
Chris