¿Tiene sentido el manejo de controles de formulario ocultos en HTML5?

Question

HTML5 agregado en la capacidad de definir mejor la validación del lado del cliente en formularios sin necesidad de usar JavaScript. El concepto ya existía con atributos como "maxlength" y "minlength". Se ha ampliado con atributos como "requerido" y "patrón". Sin embargo, HTML5 también ha definido límites en estos atributos y los navegadores WebKit han implementado estas restricciones (probablemente Firefox y Opera no se quedan atrás).

El restrictions in question tiene que ver con la visibilidad del control de formulario cuando está oculto por CSS/JavaScript usando las reglas de CSS display: none o visibility: hidden. Las restricciones se definen como:

4.10.7.1.1 estado oculto

Cuando el tipo de atributo de un elemento de input está en el estado oculto [...] El elemento input representa un valor que no es destinado a ser examinado o manipulado por el usuario.

[Además,]

• El atributo value IDL se aplica a este elemento y está en modo por defecto.
• Los siguientes atributos de contenido no deben ser especificadas y no se aplican al elemento: accept, alt, autocomplete, checked, dirname, formaction, , formmethod, formnovalidate, formtarget, height, list, max, maxlength, min, multiple , pattern, placeholder, readonly, required, size, src, step y width. atribuye
• El siguiente IDL y métodos no se aplican al elemento: checked, files, list, selectedOption, selectionStart, selectionEnd, selectionDirection, valueAsDate, y atributos valueAsNumber IDL; select(), setSelectionRange(), stepDown() y stepUp() métodos.
• Los eventos input y change no se aplican.

A primera vista, tiene sentido decir que la validación no debería necesitar ser realizado en forma de controles que el usuario tiene el control sobre. Y, para los formularios creados con los elementos de control de formulario predeterminados, estos tienen sentido. Pero ahora, ha surgido un problema con la construcción de controles de forma remota.

Ni HTML5 ni CSS3 (ni los principales navegadores) han simplificado mucho el estilo de los controles de formulario. Los elementos <select> siguen siendo muy restringidos en términos de diseño y los elementos <input> y <button> tienen reglas de estilo molestamente diferentes (y para los navegadores que no son IE, la orientación de navegador CSS casi imposible). Como tal, cuando mis diseñadores quieren controles de forma "bonitos", es posible que necesiten reconstruirse usando HTML, CSS y JavaScript. El control simulado controlará de forma remota el control real que está oculto por CSS.Esto se aplica a los elementos <select>, <input type="checkbox"> y <input type="radio">, todos los cuales causan un problema en los navegadores WebKit cuando se les da el atributo required.

Dado que la especificación HTML5 establece que ciertos atributos, como required, no pueden existir en los controles de formulario ocultos, los exploradores deberán responder a los atributos no válidos. Los navegadores WebKit están respondiendo al no enviar el formulario (y no desencadenar el evento de JavaScript submit). Me estoy encontrando con el error ahora con un elemento <select>.

cromo produce este error en la consola:

un control de formulario no válido con el nombre = 'elemento nombre' no es enfocable.

Safari falla al mostrar una barra gris en la parte inferior de la ventana con el mensaje:

favor, seleccione un elemento de la lista

---

Por lo tanto, mi preocupación es si HTML5 es demasiado restrictivo o me estoy acercando a este problema de forma incorrecta. O bien:

1. La especificación de HTML5 es defectuosa y agrega una restricción adicional sin otra solución. HTML5 asume que si un control de formulario no está visible, el usuario no debería poder interactuar con él. Esto evita que los desarrolladores utilicen los atributos de validación de HTML5 para los elementos que controlamos de forma remota, mientras que se deja oculto el control de formulario original. Todavía no tenemos la capacidad de crear nuestros controles personalizados usando solo CSS, lo que requiere que todavía los construyamos nosotros mismos.
2. Manejo incorrecto de controles de formulario remotos. como estoy usando una técnica "vieja" para resolver un problema que muy bien puede haber sido redefinido, es posible que mi enfoque sea obsoleto. También es posible que, dado que WebKit sea el único que maneje esta restricción en este momento, WebKit tenga una solución alternativa para esto que aún no haya encontrado.

Las únicas soluciones que se me ocurre en este momento son a

• Retire los atributos restringidas siempre que dinámicamente ocultar un control de formulario con JavaScript, lo que significaría que sacrifico de validación de HTML 5,
• Muestra temporalmente y oculta inmediatamente los controles de formulario infractores, aunque no estoy seguro de cuándo se realizará, ya que el evento submit nunca se activa y es posible enviar un formulario sin activar el evento click en el botón de envío, o
• Utilice el atributo novalidate, aunque aún perdería la validación HTML5.

¿Estoy viendo esto correctamente o me falta algo?

P.S. Perdón por la duración. Todo después del descanso es mi "tl; dr".

Answer 1

Primero confunde dos cosas. Si la especificación de HTML5 dice estado oculto, la especificación solo significa un elemento de entrada con un atributo de tipo establecido en el valor "oculto". En este caso, la entrada no está validada, lo que significa que la entrada no puede ser inválida. Y el navegador no aborta el envío de formularios.

Tu problema es otro problema. Tiene un elemento inválido verdadero, que solo está visualmente oculto (usando display: none) y reemplazado por otro elemento (o por un conjunto de otros elementos). En su caso, el problema es el siguiente: Por especificación en caso de validación de formulario interactivo, el navegador debe enfocar el primer elemento no válido y mostrar al menos para este elemento un mensaje de validación. El problema es que un navegador no puede enfocar un elemento oculto ni mostrar un mensaje de validación debajo de este elemento. Lo que significa que el navegador detiene la presentación del formulario, pero tiene una interfaz de usuario impar para mostrar los problemas de validación.

Ahora a su: ¿Esto tiene sentido? Sí, lo hace! Si cambia la UI de un elemento de formulario, debe implementar también la IU para el mensaje de validación. (Si desea personalizar algo, tiene que personalizar todo lo que desea usar). HTML5 le proporciona una API para lograr exactamente esto.

Debe enlazar el evento no válido de su elemento seleccionado, luego evitar la acción predeterminada (si es el primer evento no válido del formulario) y colocar su propia información de herramientas de validación en el elemento de selección con estilo.

En mi forma HTML5 polyfill (webshims lib), ya estoy usando código para vincular un elemento nativo (con API) con otro elemento + generando simplemente tooltips de validación.

He creado un jsfiddle simple, que imita un reemplazo de selección y muestra cómo lograr la validación de formularios HTML5 con controles de formularios personalizados. Puede encontrar el example here.