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

label html

Question

Se agregó HTML5 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 con Firefox y Opera no muy por detrás).

Las restricciones en cuestión tienen que ver con la visibilidad de un control de formulario cuando están ocultas por CSS / JavaScript usando la display: none o visibility: hidden reglas de CSS visibility: hidden . Las restricciones se definen como:

4.10.7.1.1 Estado oculto

Cuando el atributo de tipo de un elemento de input está en el estado Oculto [...] El elemento de input representa un valor que el usuario no debe examinar ni manipular.

[También,]

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

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

Ni HTML5 ni CSS3 (ni los principales navegadores) han facilitado mucho el estilo de los controles de formulario. <select> elementos <select> todavía están muy restringidos en términos de estilo, y tanto los elementos <input> como <button> tienen reglas de estilo muy diferentes (y para los navegadores que no son IE, la orientación del navegador es casi imposible). Como tal, cuando mis diseñadores quieren "bonitos" controles de formulario, es posible que deban reconstruirse utilizando HTML, CSS y JavaScript. El control simulado controlará de manera remota el control real que está oculto por CSS. Esto se aplica a los elementos <select> , <input type="checkbox"> y <input type="radio"> para mí, todo lo cual causa un problema en los navegadores WebKit cuando se proporciona el atributo required .

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

Chrome falla con este error en la consola:

Un control de formulario no válido con nombre = '' nombre-elemento '' no se puede enfocar.

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

Por favor seleccione un artículo en la lista

Por lo tanto, mi preocupación es si HTML5 es demasiado restrictivo o me estoy acercando a este problema incorrectamente. Ya sea:

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, dejando el control de formulario original oculto. Todavía no tenemos la capacidad de crear nuestros controles personalizados utilizando solo CSS, lo que requiere que nosotros también los construyamos nosotros mismos.
2. Estoy manejando los controles remotos de forma incorrecta. Como estoy usando una técnica "antigua" para resolver un problema que muy bien se puede haber redefinido, es posible que mi enfoque esté desactualizado. También es posible que, ya que WebKit es el único que maneja esta restricción en este momento, WebKit tiene una solución para esto que aún no he encontrado.

Las únicas soluciones que puedo pensar en este momento son

• Eliminar los atributos restringidos siempre que oculto dinámicamente un control de formulario con JavaScript, lo que significaría que sacrificaré la validación de HTML5,
• Mostrar y ocultar de forma temporal los controles ofensivos del formulario, aunque no estoy seguro de cuándo se haría esto ya que el evento de submit nunca se dispara y es posible enviar un formulario sin disparar el evento de click en el botón de envío, o
• Usa el atributo novalidate , aunque todavía perdería la validación de HTML5.

Entonces, ¿estoy viendo esto correctamente o me estoy perdiendo algo?

PD Perdón por la longitud. Todo después de la pausa es mi "tl; dr".

Answer 1

Primero mezclas dos cosas. Si la especificación 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 se valida, 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. Tiene un verdadero elemento no válido, que solo se oculta visualmente (con display: none) y se reemplaza por otro elemento (o por un conjunto de otros elementos). En su caso, el problema es el siguiente: por especificación, en el caso de la validación de formularios interactivos, 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 el envío del formulario, pero tiene una IU impar para mostrar los problemas de validación.

Ahora a tu: ¿Tiene esto sentido? Sí, lo hace! Si cambia la interfaz de usuario de un elemento de formulario, debe implementar también la interfaz de usuario para el mensaje de validación. (Si desea personalizar algo, ha personalizado todo lo que desea usar). HTML5 te da una API para lograr exactamente esto.

Debe vincular 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 sobre herramientas de validación en el elemento seleccionado con estilo.

En mi formulario Polyfill de HTML5 (webshims lib), ya estoy usando código para vincular un elemento nativo (con API) con otro elemento + generando simplemente información sobre herramientas de validación.

He creado un jsfiddle simple, que imita un reemplazo selectivo y muestra cómo lograr la validación de formularios HTML5 con controles de formularios personalizados. Puedes encontrar el ejemplo aquí .