31232 - RFE - Tab in textarea really work as #spaces when desired.

Status: NEW

(Core :: Layout: Form Controls, enhancement, P3)

Description

[/\/\arcio Galli]

Someone commented about a bug whose tag inside textarea is doing spaces instead 
navigate through form fields. Is there a way, via JavaScript, to disable the 
correct feature (navigation between fields) and in fact enable for example
 N spaces tab?

If not, inside the text field, can we intercept the event of the tab? and avoid 
the navigation between form fields? using DOM2?

if not. It's a RFE. Because I think users will try, now, to make editors inside 
Netscape. And if tab (spaces) is not going to work, so they will have to code 
from scratch a textarea written in JavaScript and DOM1/2.

Comment 1

[Sean Richardson]

It does seem likely that someone will want to build an editor inside the 
browser.

See also bug 29086, "Tabbing within TEXTAREA removes focus from text field":
apparently entering tabs within the textarea is standard behavior in NN 4.x on 
the Mac; see the 2000-02-24 comment by [e-mail].

There remains the problem of how to leave the textarea if tab is not doing that
job; cc-ing [e-mail] and [e-mail], who are already looking
into that problem.

It may make sense to do this as a CSS property as well as well as through js
DOM manipulation; py8ieh=[e-mail], does this make any sense as a
proposal for CSS3?

Comment 2

[Gervase Markham [:gerv]]

*** Bug 32653 has been marked as a duplicate of this bug. ***

Comment 3

[Matthew T (active 1999-2002)]

If a particular Web app wants spaces instead of tabs, surely the author can just 
write JavaScript to do an auto-replace on the text as it is entered -- or even as 
it is submitted? That way it could have an app-specific number of spaces, it 
could do things the other way around (converting spaces to tabs), etc etc.

I don't think this is something the user agent should care about. And entering a 
string of consecutive spaces definitely isn't important enough to sacrifice a
<modifier>+Tab assignment for.

Comment 4

[rods (gone)]

I really don't think this is my issue.

Comment 5

[Jesse Ruderman]

> surely the author can just write JavaScript to do an auto-replace on the 
> text as it is entered 

i think the problem is that tabs would otherwise be interpreted as "go to the 
next field", which is hard for javascript to capture.

Comment 6

[Hixie (not reading bugmail)]

This _could_ be something the CSS working group would want to think about, if
we want to move this further then someone will have to post to www-style and
suggest it (if it hasn't already been suggested).

Eric, is this important enough for Netscape's FCS? I'm guessing that it is not
and marking it Future, helpwanted.

Comment 7

[ekrock's old account (dead)]

A "nice to have" ENH --> confirming FUTURE. Ian's correct as usual ...

Comment 8

[bsharma]

Updating QA contact.

Comment 9

[Lakespur Roca]

Just as a note: Tab in the browser should do only one thing in this case and 
that is to move the focus from one item to another. This is so importiant 
becasue the tab key is relied on for this purpose. Taking the tab event to 
put in speces when in a field leaves the user stuck in that field with no 
obvious way to get out. This is currently a problem with build for 9/26. There 
is no way to continue filling a form once you get into a multiline text firld. 
Tab is currently Broken.

Comment 10

[Vladimir Ermakov]

QA Contact Update

Comment 11

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 12

[Reinout van Schouwen]

There was a lengthy discussion on this issue on the GNOME usability mailinglist.
See: 
http://mail.gnome.org/archives/usability/2001-October/msg00000.html

My opinion on this is, that I *expect* a multiline textfield (and ONLY a
multiline textfield) to accept tabs. When it does not it is very confusing to
me, which is why I ended up writing this comment in the first place. Moving out
of the multiline widget can always be accomplished with Ctrl+Tab, for instance.

Comment 13

[Christopher Hoess (gone)]

->[e-mail], attinasi isn't about to spend time on this.

Comment 14

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"