Short Description
|
use of tabindex on all input fields
|
Entered
|
By:
PeteL
When: 1998-06-02 10:50:54 Build: 1.03.13b
|
Categories
|
Type:
Suggestion
Department: Product
Category:
HTML Generation
|
Description
|
one of the environment differences between native 3270 and HTML is the potentially changed default tab sequence on the screen. each time a link is added to the form, a new tabstop is also added. this is generally not appreciated by 3270 keyers, and can easily be overridden by (optional?) addition of tabindex to all input fields. it could be set to 1 for all fields, which would cause all input fields to be tabbed to in sequence, while skipping over all hypertext links.
|
|
Append
|
By: WindSurfer When: 1998-06-02 11:19:30 New Status:
Pending Customer
|
Comment
|
This sounds like a real biggy.
Problem is, Netscape 4 doesn't support the tabindex attribute, unless you've tested it-- I researched in Newsgroups and IE-to-Netscape comparison sites and all indicate that only Internet Exploder 4.0 supports the tabindex attribute.
I found one newsgrouper that was fiddling with the 1.2 event model and capturing TAB key events-- he was stumped on what he was trying to do, but apparently you can get an event on the KEYUP event-- at this point, the new object has focus, so you can check if the class of the object is an anchor, then test if the shift key is pressed. If the shift key is pressed, you go back in the current forms array until you find a non-anchor object, then tell it to grab focus. If the shift key isn't pressed you move forward through the forms array until you find a non-anchor element.
If you see if it will work, I'll make it an option on the <TEFORM> and <TEMACRO TERMFORM> tags :)
|
|
Append
|
By: PeteL When: 1998-06-03 06:50:35 New Status:
Pending IE
|
Comment
|
excuse the french, but DAMMIT! you're quite right, according to probably the exact same sources. I stupidly enough was doing my research at the W3C site, and never checked for adequate browser support. When will this insanity end?!?!?
I may be able to do something along the lines of what you suggest. I already build an array of the input items when the page is loaded so that I can support my auto-cursor-jumping feature, so it may be even simpler for me to do this - all I need is the element number of the field getting focus, and I can locate that offset in my array, and go forward or backward based on the shift-key. However, I need to figure out what level I have to capture the keystrokes - I'm capturing now at the form level, I may have to move up to the window or frameset.
|
|
Append
|
By: WindSurfer When: 1998-06-08 13:43:20 New Status:
Pending Customer
|
Comment
|
Any progress on this front?
Got some sample JavaScript you'd like to share, at least on getting the keystroke events in a Screensurfer environment?
We would like to plug-in an option on the new <TEFORM> tag to implement "link-skipping" on a generic basis and are always interested in saving time :)
|
|
Append
|
By: PeteL When: 1998-06-08 14:01:19 New Status:
Pending IE
|
Comment
|
you know, i sort of forgot about this. i was happy enough that i got some very small semblance of the stylesheet spec to work right, so that bold input fields could be noticed (Netscape, at least, only supports italic, line-through, and underline for altering font within a form input field, so we settled for italic and underlined. works well, after most of an entire day doing research and testing. I think the ease of implementing this may have actually caused me to eliminate the code I was thinking of using for tabindex support. i'll have to give it some more thought.
|
|
Append
|
By: PeteL When: 1998-06-09 07:45:14 New Status:
Pending IE
|
Comment
|
sending up the keyhandling stuff I am using via email.
|
|
Append
|
By: PeteL When: 1998-07-01 07:38:59 New Status:
Closed
|
Comment
|
since there is no tabindex in the 4.05 (current) build of netscape, this cannot be handled. hopefully the new release will include this function. i think i may have another suggestion ticket (#60?) that could address this issue, since it requests the ability to globally alter field generation. if this is satisfied, tabindex could easily be added once it's available (and IE 4.0 users could do it today).
|