"Aplicaciones" Web: Ni el foco pueden controlar!

En Swing se puede navegar de un componente a otro usando las teclas Tab o Shift-Tab. Estas teclas son las "teclas de recorrido de foco" (focus traversal keys) y pueden ser cambiadas programaticamente. Por ejemplo, tu puedes agregar la tecla Enter a la lista de teclas de recorrido de foco con el siguiente codigo:

Set forwardKeys = getFocusTraversalKeys(
    KeyboardFocusManager.FORWARD_TRAVERSAL_KEYS);
Set newForwardKeys = new HashSet(forwardKeys);
newForwardKeys.add(KeyStroke.getKeyStroke(KeyEvent.VK_ENTER, 0));
setFocusTraversalKeys(KeyboardFocusManager.FORWARD_TRAVERSAL_KEYS,
    newForwardKeys);

Y eso es todo, asi de facil se puede usar Enter en ves de tab para mover el foco al siguiente elemento. Simple no? Ahora trata de hacerlo con JavaScript en una forma de HTML:

No se puede. O tal ves si, pero nadie sabe como.
Hay algunas soluciones parciales, por ejemplo, esto solo funciona en IExplorer:

<INPUT TYPE="TEXT" onKeyDown="if(event.keyCode==13) event.keyCode=9;">

Pero no en Firefox (ni en Safari, Ni en Opera, ni en... ). Otros atrapan el keyCode 13 y buscan el componente con el siguiente tabindex (pero eso solo funciona si tiene configurada la propiedad tabindex para todos los elementos de tus formas, y se complica rapidamente si llegas a tener que construir la forma dinamicamente o si quiere reutilizar componentes)

En Explorer, simular el evento resultante de presionar la tecla tab es tan simple como event.keyCode=9;, en Firefox, el codigo equivalente seria:

var newEvent = document.createEvent("KeyEvents");
                newEvent.initKeyEvent("keypress", true, true, document.defaultView,
                                event.ctrlKey, event.altKey, event.shiftKey, event.metaKey, 0,
                                9);
                event.preventDefault();
                event.target.dispatchEvent(newEvent);

Pero Firefox (la version que tengo es la 3.5.7) en vez de mover el foco... escribe un caracter "tab" dentro del inputtext!!!!!!

Si cambio a :

newEvent.initKeyEvent("keypress", true, true, document.defaultView,
                                event.ctrlKey, event.altKey, event.shiftKey, event.metaKey, 9,
                                0);

simplemente no pasa nada... Como es posible que no haya un modo de simular un teclazo a "tab"?!

Este, y muchos otros modos de controlar el foco (como los focus cycle root), disponibles en Swing, simplemente no esta disponibles para aplicaciones HTML+JavaScript. Al menos no de forma obvia y sin tener que hacer esfuerzos considerables.

Por ejemplo, hasta donde se, simplemente no hay un equivalente a la clase FocusTraversalPolicy en el API de HTML+JavaScript....

Veamos otro ejemplo: que pasa con el foco cuando se quieren implementar componentes reutilizables entre diferentes paginas? Al parecer, no existe un modo de definir tab scopes/focus cycle root en HTML, asi que si se tiene definidos el tabindex 2 componentes independientes, y estos 2 componentes se utilizan en una misma pagina, el resultado sera un completo caos

Ejemplo (con JSF y Facelets, pero segun yo afectaria igual a otros frameworks de componetes como por ejemplo Tapestry... o no?)

Componente 1

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
>
 
 A <h:inputText value="" tabindex="1" />
 B <h:inputText value="" tabindex="2"/>
 
</ui:composition>

Componente 2

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
>
 
 C <h:inputText value="" tabindex="1" />
 D <h:inputText value="" tabindex="2"/>
 
</ui:composition>

Uso en la pagina:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
 template="layout/template.xhtml">
<ui:define name="body">
 
<ui:include src="/Componente1.xhtml" />
 
<br/>
 
<ui:include src="/Componente2.xhtml" />
 
</ui:define>
 
</ui:composition>

Lo que yo quisiera que pasara, es que el foco se moviera: A -> B ->C -D, pero no, se va a mover A->C->B-D.

Llegue a pensar que tal ves se podria controlar haciendo esto:

<div tabindex="1">
<ui:include src="/Componente1.xhtml" />
</div>
 
<div tabindex="2">
<ui:include src="/Componente2.xhtml" />
</div>

Pero no, no tiene ningun efecto, HTML simplemente no tiene concepto de tab scopes/focus cycle root. Lo curioso es que he buscado en Google soluciones para este problema y no encuentro nada preconstruido que lo resuelva... tal pareciera que o nadie hace componentes reutilizables... o nadie utiliza navegacion por teclado... sospecho que lo mas probable es que (casi) nadie utilice componentes reutilizables... (ciertamente JSF no tiene ninguna solucion out-of-the-box, que yo sepa ni en JSF 2.0... lo cual hace todas las nuevas caracteristicas para facilitar la creacion de componentes algo totalmente inútil para cualquier forma de captura no trivial)

Como controlan ustedes el foco? He buscado ejemplos en Google, pero la mayoría son formas de juguete para aplicaciones también de juguete, nada realmente complicado, nada como lo que en verdad es necesario construir para uso interno de una empresa (y sin embargo, las empresas siguen pidiendo aplicaciones para webbrowser y los desarrolladores siguen ofreciéndolas en un circulo vicioso que parece no tener fin...).

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Nadie usa navegación por teclado

Esto no ha sido un verdadero problema porque la gente usa el mouse para todo. Esto ha sido una limitante de HTML desde el principio, porque no estaba pensado para eso. Javascript, AJAX, etc son parches que se han puesto encima de HTML para poder hacer aplicaciones más dinámicas en web sin tener que recargar páginas completas para todo y también sirven para poder hacer algo de validación del lado del cliente, agregar algunos adornos, etc pero no vas a tener la misma funcionalidad que en una aplicación de escritorio.

Supongo que ya revisaste ZK y otros frameworks de AJAX que presumen de darte la misma funcionalidad que una app de escritorio (y tienen algunos demos bastante impresionantes). Hace poco vi esta demo de HTML5 que es básicamente un programa para dibujar. No sé cómo se puede hacer todo y eso y no se puede controlar el foco de los campos... Tapestry 5 tiene un scriptsito para encontrar si hay algun campo de texto en una página y de ser así, selecciona el primero que se encuentra, lo cual es muy útil para páginas por ejemplo con un campo de búsqueda o de login, etc para que ya tengas el foco en el campo donde vas a teclear algo.

Imagen de ezamudio

Usabilidad

Y por cierto, no estás dándole en la torre a la usabilidad con eso de cambiar el TAB por ENTER? El estándar es que ENTER es para causar una acción y TAB para cambiar de foco.

Imagen de luxspes

Usabilidad es relativa

Si, yo se que estándar es que ENTER es para causar una acción y TAB para cambiar de foco. Pero el problema es que los que le vendieron otras chorromil aplicaciones a este cliente no lo saben... asi que sus usuarios ya estan acostumbrados a usar al ENTER de este modo, asi que adentro de la organizacion, el ENTER es para cambiar de foco y para causar acciones (si esta sobre, por ejemplo un boton, aunque a veces es medio incosistente y ocurre cuando por ejemplo,se esta en el ultimo inputtext de una linea en una tabla) es el estandar.

Imagen de luxspes

Frameworks AJAX

Si, frameworks AJAX mas elaborados com ZK, Echo, OpenLaszlo, etc ofrecen mejores manejo en muchos sentidos (no se si en este), el problema es que también te obligan a construir toda la aplicación a su manera y lo mas comun en las empresas hoy en dia es encontrarte personas que manejan algo de javascript, hacen sus interfaces en Dreamweaver y usan Java para guardar en la base de datos... si les dices que ahora ya no van a poder usar Dreamweaver y que ZK, Echo, etc no tienen nada que se le compare... pues no le entran aunque acabe saliendoles mas caro el final por las horas de desarrollo perdidas (o quien sabe, por que la curva de aprendizaje tal ves resultaria demasiado empinada... y tal vez al final de cuentas el Browser esta tan limitado que ni con ZK o Echo se puede controlar el foco en tal o cual situacion... y seria gacho descubrir eso después haber invertido tiempo en aprender...)... lo ideal seria un plugin de jQuery que resolviera estos problemas... pero no encuentro ni uno :'(

Imagen de ezamudio

Ligas

Has visto esto? No es precisamente lo que buscas, pero pues es una idea alternativa para lo del cambio de foco, usando varios estilos, aunque no abarca lo del ENTER:

http://greatwebguy.com/programming/dom/input-focus-with-jquery/

Esto es muy similar:

http://stackoverflow.com/questions/267615/focusing-first-control-in-the-...

Imagen de luxspes

Con que HTML5 tuviera un

Con que HTML5 tuviera un KeyboardNavigationMode como el de XAML... jajaja.... sueños guajiros....
Me pregunto si es posible calcular el numero de horas hombre perdidas reinventando un manejo decente de interfaz dentro del browser.... supongo que no... no es algo que, por ejemplo, se pueda ver en un plan de trabajo en diagrama de gantt hecho al inicio de un proyecto: "XXX horas en implementar manejo de foco decente"o "XXX horas manejando el foco manualmente control por control en todas las pantallas".
Y todavía nos sorprendemos cuando se retrasan los proyectos ;-)

Imagen de luxspes

Gracias por ligas, pero....

Si, jQuery ayuda a aligerar la carga del desmedido uso del browser en estos tiempos... pero al final, también se queda corto... (no parece haber ningun jQuery plugin que resuelva definitivamente lo planteado en este blog post... tal ves por que simplemente va mas alla de las capacidades de la plataforma?)

Imagen de luxspes

Problemas distintos, enfoques distintos, soluciones distintas

Lo triste es que el mito de que el browser es suficiente para cualquier aplicación crece dia a dia, en van apareciendo mitos derivados, que engañan a las personas haciéndoles creer que lo que sirve para Google, sirve para una aplicación empresarial.... y no es asi, son problemas completamente distintos, que requieren herramientas y enfoques bien diferentes.

Imagen de ezamudio

Specs...

Al final el problema sigue siendo el mismo: especificaciones irracionales. El control de foco en tu aplicación web es un curita que le quieren poner al problema de que ya se rompió la usabilidad y la van a seguir rompiendo en esa organización. Cuando entra gente nueva a ese lugar, tiene que recapacitarse en el uso de la computadora si ya está acostumbrada a usar TAB para cambiar de campo y ENTER para causar una acción; y cuando se vaya de ahí, nuevamente tendrá que usar el estándar y olvidar la manera en que se usaba en ese lugar.

Eso causa como dices una pérdida de tiempo, porque aunque al final encuentres la solución, tuviste que invertir mucho tiempo en un requerimiento que honestamente es superfluo. El cliente debe entender que está pidiendo cosas superfluas y que las debe pagar y con mucho gusto se le hacen.

Imagen de luxspes

Enter to Tab pasa, pero y la falta de focus cycle root?

Pues, si en el caso del primer ejemplo, es superfluo, pero en el segundo caso y tercer caso (falta de FocusTraversalPolicy y falta de tab scopes/focus cycle root) no hay disculpa que valga...

Imagen de benek

Es el costo de querer emular...

Es el costo de querer emular las aplicaciones de escritorio, cuando las aplicaciones web no surgieron por los mismos motivos ni objetivos.

Como dices, se pudo haber aprovechado la versión 5 para darle solución de fondo a este problema, creo que hubiera sido una nimiedad si se lo hubieran planteado, al igual que ezamudio yo también vi el "paint" que hicieron con HTML5 y si se diseñó HTML5 para crear eso sin necesidad de Flash el remodelar la navegación de los sitios web hubiera sido cosa fácil, IMHO, al fin el W3C solo tiene que hacer la especificación y los navegadores seguirla.

Claro que también veo un problema que no es tecnológico, sino administrativo en tu(s) caso(s). Se me figura que tus usuarios son de aquellos que utilizaban terminales en C en donde no había ratón y todo lo solucionaban con el teclado, y ya hasta ágiles eran y a huevo quisieron que el nuevo sistema sea así, resistiéndose al cambio y a que las nuevas tecnologías se manejan diferente, como dije en el título, es el costo de querer emular lo legacy y no resistirse a adoptar las nuevas formas y tecnologías.

Saludos.

Javier Ramírez Jr.

Imagen de luxspes

No todo lo viejo es malo, no todo lo nuevo es bueno

Exacto, es el costo de querer emular lo legacy, el problema es que es un costo dificil de hacer visible y de justificar:
Primero por que: ¿Como le explicas al usuario que tu nueva super-plataforma-web-maravillosa no puede controlar el foco? y segundo por que muy probablemente ni te esperas que falle de este modo tan patético ¿Como es posible que te vendan las caracteristicas para hacer componentes (en Facelets, o en JSF 2.0 o en Tapestry) sin la capacidad para manejar el foco coherentemente? ¿Que no se dan cuenta de que el resultado es algo inutil? En otra industria, casi se le podria llamar a esto fraude...

Aun si no hubieran pedido la traduccion del Enter a Tab, de todas forma hubieran salido mal las cosas por la falta de "tab scopes/focus cycle root" algo que es es posible hacer con Swing (y facilisimo de hacer con XAML). El problema como yo lo veo, no es solo que los usuario se resistan a modernizarse, sino que los desarrolladores en nuestro deseo de modernizar, nos olvidamos de verificar que lo nuevo de verdad sea mejor para los requerimientos... en este caso, las aplicaciones web, se desarrollan por todo y para todo, muy por encima de sus capacidades, como si fueran lo mismo que las aplicaciones de escritorio "solo que mejor por que no hay instalar, no mas hay que tener el browser"... y eso es mentira... pero esta tan extendido que tratar de vender una aplicacion "no web" es muy dificil, los clientes "esperan que sea web" por que "web es lo ultimo y lo mejor" aunque no tengan ni idea de lo que estan diciendo... supongo que el karma de fomentar el web como una panacea esta alcanzando a industria una ves mas...

Imagen de ezamudio

Parche temporal...

Dependiendo el framework que uses, tal vez podrías buscar la forma de llevar un contador a nivel página al momento de hacer el render de la misma, para que todos los elementos que tengan un tabindex, se vaya incrementando segun este contador (tomando en cuenta obviamente el tabindex que indican dentro de cada componente).

De esta forma si tu componente1 tiene dos elementos con tabindex 1 y 2, y el componente2 tiene elementos con tabindex 2 y 1, si los incluyes varias veces dentro de la misma página (incluso dentro de un loop), vas incrementando ese tabindex según el contador global pero respetando los tabindex internos (sumándole el valor que indican al contador global)

Es decir, tu tabindex global (TIG) comienza en 1 y si encuentras elementos en la página que lo necesitan, se los vas poniendo. Cuando encuentras un componente le sumas lo que ya lleva el TIG al entrar al componente a cada tabindex, y al final incrementas el TIG por el número de elementos que traía el componente.

Pero igual es muy engorroso y lo pudieron haber hecho los diseñadores del framework...

Imagen de arturotena

Es contra los estándares

Jajaja. Te entiendo. Donde trabajo hay algunos usuarios que pidieron que se usara Enter para moverse entre campos en una aplicación Swing. Y al cliente, lo que mande. Por supuesto, es salirse de los estándares de HCI de Windows (y la mayoría de los otros SO también), pero qué le vamos a hacer.

Imagen de arturotena

Reeducación

Yo opino que los reeduques. Déjales el Tab.

Imagen de arturotena

El mouse y el teclado

Sí, la mayoría de la gente usa sólo el mouse para moverse entre controles, ya sea en aplicaciones de escritorio o Web. Sin embargo, habemos usuarios que preferimos el teclado. No somos power-users ni nada, pero se nos hace más cómodo. Una de mis usuarias tiene levantadas varias peticiones en un sistema para que mejoremos esa parte. A sí que, al menos ya somos 2 =). Además, por usabilidad, es necesario permitir usar sólo el teclado. Las human interface guidelines de varios SO lo especifican.

Imagen de arturotena

El mouse y el teclado

Nosotros hicimos un sistema donde losarchivos HTML los programaban diversas personas. Lo que hicimos fue definir rangos para los tabindex: del 0 al 99 el menu. Del 101 al 200 el header. Del 201 en adelante el body. Y dentro del body, hubo más rangos. Espero te sirva.

Imagen de luxspes

Parche temporal: Algo asi estaba pensando...

Si, algo asi estaba yo pensando hace algun tiempo, crear un plugin the jQuery que, cuando le pasaras algo como:

<div tabindex="1"  class="tabscope">
 A <input type="text"  tabindex="1"/>
 B <input type="text"  tabindex="2"/>
</div>
 
<div tabindex="2" class="tabscope">
C <input type="text"  tabindex="1"/>
D <input type="text"  tabindex="2"/>
</div>

detectara a los elementos con la style class tabscope y entonces buscara que elementos tiene adentro del dom,y modificara el tab index para producir algo como (basicamente combina el tabindex del div dentro de los inputText):

A <input type="text"  tabindex="11"/>
B <input type="text"  tabindex="12"/>

C <input type="text"  tabindex="21"/>
D <input type="text"  tabindex="22"/>
 

pero pues ya cuando lo combinas con otros efectos AJAX que puedas llegar a necesitar y con varios niveles anidados de scope... sobretodo si es necesario alterar el DOM para agregar o quitar elementos... pues podria llegar a complicarse bastante...
Lo que no me explico es por que JSF 2.0 no incluye nada asi.... ni Tapestry... por que si no, ya lo hubieras presumido ;-)

Imagen de ezamudio

No sé

No sé si Tapestry lo trae o no lo trae. Como no he tenido ese problema la verdad ni me he metido a ver si hace algo así. No puedo afirmarlo ni negarlo, ni tengo tiempo de investigarlo por el momento.

Imagen de luxspes

Que no sepas ya dice mucho...

Bueno, el hecho de que no sepas si Tapestry lo trae o no lo trae ya dice mucho... esto es algo que debería ser parte de los tutoriales mas básicos para crear componentes... asi que si no lo conoces, yo apostaría a que no lo tiene ;-)

Imagen de luxspes

Rangos: Experiencia real en campo

Si, la idea de los rangos es la solucion mas simple, y la que generalmente termina uno usando... solo que cuando lo ves en retrospectiva... que caso tiene tener tecnologías de componentes como Facelets, JSF 2.0, Tapesty, etc, etc, si uno tiene que estarse preocupando por estos rangos... diera la impresion de que los que crean todas estas tecnologias no tienen mucha experiencia trabajando "en campo", "en el mundo real", "aqui afuera", donde ese necesario implementar super parches como este de los rango para hacer funcionar una tecnologia de componentes que deberia de resolver estos problemas de forma intrinseca

Claro que eso suena un poco injusto, al final si resuelven otro monton de cosas comunes... o no? Supongo que lo que me molesta es lo dificil que es predecir cuando la abstraccion del framework fallara y me hundira en interminables horas perdidas resolviendo un problema que ni siquiera debiera existir...

Imagen de ezamudio

autores

No sé quiénes sean los autores de los otros frameworks pero Howard Lewis Ship (el autor de Tapestry) fue mucho tiempo empleado de una empresa llamada Formos y ahora es consultor independiente, tiene clientes "aquí afuera", "en el mundo real" o como le quieras llamar. Podrían subcontratarlo y aventarle ese problema para que lo solucione incluyendo algo en el framework... o esperar a que se tope un día con un cliente que quiere exactamente lo mismo que tu cliente.

Lo que quiero decir es que no todos los proyectos de aplicaciones web se topan con este problema que estás teniendo. En la mayoría de los casos muy probablemente porque el usuario no lo considera un problema, o no es prioritario. Pero pues si fuera algo realmente tan grave en todos los proyectos web creo que habría miles de foros donde mucha gente pregunta lo mismo que tú y ya muchos tendrían distintas respuestas y maneras de resolver el problema.

Ya varios estamos de acuerdo contigo en que es un problema hasta de diseño, ya sea de los frameworks o hasta de HTML. Puedes enviar una petición a la W3C, describiendo el problema para ver si lo meten a la spec de HTML6 o lo que sea. O contactar a los autores del framework que estás usando actualmente, para ver si tienen idea cómo resolver ese problema, y luego avisarle a los autores de los otros frameworks para que no se queden atrás porque el que usas ahorita ya tendrá esa solución en algún momento (en el peor de los casos que te incluyan en el proyecto del framework que usas ahorita, si te ayudan a saber dónde hay que moverle y tú modificas lo necesario para que ya funcione como quieres, les mandas el parche o haces commit y ya que el siguiente release incluya las mejoras que le hiciste).

Imagen de Shadonwk

ami tambien...

yo tambien me he topado con usuarios que quiren hacer el cambio del foco con el enter.. y a quienes requerian aplicaciones por ejemplo vb pues si se los hacia claro que por un costo extra (la flojera cuesta) y pero donde no habia una manera facil de hacerlo o no la conocia simplemente se les daba una clase del porque deberia de hacerlo asi y algunos entendian algunos no pero al final acaban acostumbrandose..

Imagen de luxspes

A traducir al ingles....

Ok Chochos, supongo que no puede hacer daño escribirles a los de whatwg y ver que dicen... ya les contare... ;-)

Imagen de Nopalin

y dale con el cliente de nuevo...

Tal vez soy de los pocos que piensan "NO a todo lo que pida el cliente".

Una vez también me tope con un cliente que estaba acostumbrado a trabajar en un sistema de ms-dos, donde todo se controlaba con el teclado y las acciones se hacian con enter,si era campo de texto brincaba al siguiente campo, si era "boton" hacia la chamba. Despues se le migró a una aplicacion bajo windows y queria tambien utilizar el Enter como antes por "rapides".

En realidad te digo, que a veces tienes que decirle a tu cliente, NO, pero un no disfrazado. Le lavas el coco diciendole que los estandares de manejo de sistemas graficos dicen que la navegacion es con el tab, que no es lo mas conveniente por que a la larga en TODOs lados del SO asi aplica y al usuario probablemente le llegue a molestar, etc. En realidad que picar una tecla con el dedo meñique de la mano derecha para el enter o con el de la mano izquierda para el tab es indiferente para saltar de campo, a final de cuentas la navegacion por tecladoo existe y es igual de rapida y eficiente, solo hay que decirle al usuario que se tomen un par de dias en asimilarlo.

Independientemente de si se desarrolla un super-estándar con sus muchas implementaciones para atacar este asunto, ¿Por qué crees que los varios frmeworks aún no lo implementan?, lo primero que se me viene a la mente es que es demasiado trivial y pudiera caer en lo tonto. Así como el usuario se acostumbro a usar el ratón, así se puede acostumbrar a utilizar la mano izquierda para saltar de campo, el chiste es mi buen, que no por que el cliente lo pida significa que está en lo correcto. Tu además de ser el programador eres el que conoce esto, así que es tu trabajo hacer ver al cliente lo que realmente necesita y lo que le sirve a un futuro.

Imagen de luxspes

El usuario no siempre tiene la razon,pero no siempre se equivoca

Estoy de acuerdo en lo de enseñarle al usar el tab... pero a veces se encuentra uno con usuarios que de plano se niegan... es irracional... pero asi somos los humanos... al fin de cuentas tambien es irracional hacer aplicaciones en HTML siendo que es una plataforma que no es para eso, y ahi esta la mayor parte del mundo haciendo sus aplicaciones en HTML... como quien dice, que el que que este libre de irracionalidades lance la primera piedra ;-).

Por que creo que los varios frameworks todavia no lo implementan? bueno, Swing lo implementa... WPF lo implementa... la verdad es que casi cualquier framework que en verdad fue diseñado para este tipo de aplicaciones "de escritorio" lo implementa. Demasiado trivial? Mas bien el problema, creo yo, es que estamos acostumbrados a hacer aplicaciones con pantallas de captura super simples (casi de juguete) en donde no importa la velocidad de captura... es un tipico ejemplo de "el que tiene un martillo piensa que todos los problemas son un clavo" , en este caso, el martillo son las tecnologias web, como Html y Javascript, y el clavo, cualquier aplicacion que pida el usuario...

Re: Usabilidad es relativa

HTML simplemente no tiene concepto de tab scopes/focus cycle root.

Hay varios elementos HTML/XHTML que podrían serte de utilidad: button, fieldset (grupa controles y etiquetas relacionados entre sí), legend, label, optgroup, tabindex (especifica la posición de un elemento en el orden de tabulación en un documento), accesskey, (asigna una tecla de acceso a un elemento).

Al migrar aplicaciones de AS/400 a web en más de un ocasión me he topado con esa situación. Invariablemente los refiero al estándar en W3C. Hay un link para enviar comentarios y sugerencias.

Navegar con Enter no es un problema técnico ("hard skills"), es un problema que requiere para su solución "soft skills": "Señores, el mundo no es como ustedes quieren, sobrepónganse a eso."

Saludos

Javier Castañón

Imagen de luxspes

señores, sobrepónganse a eso

Navegar con Enter no es un problema técnico ("hard skills"), es un problema que requiere para su solución "soft skills": "Señores, el mundo no es como ustedes quieren, sobrepónganse a eso."

Mi cliente contestaría algo como: "Yo les pago para que hagan lo que yo quiero, si no pueden, buscare otro que si este dispuesto, señores, sobrepónganse a eso"