[whatwg] Web Forms 2.0

Olav Junker Kj?r wrote:
> Roman Ivanov wrote:
>>I think that web developers really need a standard on working with 
>>selection in textarea and input type=text fields.
> 
> Yes, that would be nice.
> It has been discussed before:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001996.html

    Let's take a look:

| function getcaretpos(inp)
| {
|     // for mozilla
|     if(inp.selectionEnd)
|       return inp.selectionEnd;
|
|     // for IE
|     if(inp.createTextRange)
|     {
|       var docrange = document.selection.createRange();
|       var inprange = inp.createTextRange();
|       inprange.setEndPoint('EndToStart', docrange);
|       return inprange.text.length;
|     }
|
|     return inp.value.length; // other browsers don't provide a method 
|                              // that I know of
| }

    Man, what were the IE developers smoking when they came up with 
that?  The Mozilla method is waaaaaaaaaaaay easier.

> I think the best way would be if the value attribute of an input field 
> could be treated as if it were text content of the element. Then the DOM 
> Range spec (perhaps with some extensions) would cover how selections are 
> treated.

    Then you wouldn't be able to determine the original value of the 
|value| attribute, not to mention the fact that the value couldn't be 
restored to the default when you hit a reset button...

 From http://www.w3.org/TR/html4/interact/forms.html#reset-button:
| # reset buttons: When activated, a reset button resets all controls to
|   their initial values.

 From http://www.w3.org/TR/html4/interact/forms.html#initial-value:
| ...a control's "initial value" may be specified with the control
| element's value attribute.

    So, messing with the DOM wouldn't be smart.

    Another problem, though, is the fact that user agents would have to 
support Document Object Model Range. That may be assumed as a result of 
the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
that requires DOM Range.

    Another thing is that I don't like the idea of changing the behavior 
of a specific attribute based on the value of another attribute (type), 
especially when the behavior is already defined by previous specifications.

> Also, this would make editing input and textarea elements consistent 
> with contentEditable, where the contents of an element is made directly 
> editable.

    I think I know where you're going with this one. In theory, we could 
change the behavior based on the value of a new attribute like 
|contentEditable|. I'm not sure I like this solution for simple text 
selection, though. Mozilla's method is just so darn easy. Just 
.selectionStart and .selectionEnd. Easy as cake.

Received on Tuesday, 22 February 2005 05:59:28 UTC