Blog · Formularios bien hechos
Controles nativos en un tema oscuro
Cada control nativo de formulario lo pintan dos manos: su hoja de estilos y el navegador del visitante. Sobre un fondo oscuro, la mitad del navegador sigue pintando para una página clara. La flecha invisible del desplegable, el calendario cegador, la inundación del autocompletado y la única línea de CSS que arregla la mayor parte.
La flecha que solo se ve en el Mac del diseñador
Un tema oscuro pasa la revisión igual que todos los problemas de esta serie: en las máquinas que posee el equipo. Las maquetas se ven nítidas, el pie de página oscuro con el registro al boletín se ve más nítido aún, y todos los que lo aprueban usan el mismo sistema operativo, el mismo navegador y la misma pantalla que el diseñador.
Entonces un visitante en una máquina con Windows va a abrir el desplegable de temas. O lo intenta, porque la flecha que dice «esto es un desplegable» la está dibujando el navegador en gris oscuro sobre su fondo casi negro. Lo que ve es un rectángulo mudo.
Nadie reporta un error, porque nadie puede nombrar uno. El formulario no está roto; simplemente parecía terminado antes de estarlo. Los temas oscuros tienen un modo de fallo que los temas claros nunca enseñaron a revisar: partes de un formulario no son suyas para darles estilo, y esas partes presuponen una página clara hasta que se les diga lo contrario.
Dos manos pintan cada control
Su CSS controla las partes de un campo que siempre ha controlado: la caja, el borde, el texto, el fondo. Pero un control nativo tiene partes que la página nunca toca. La flecha del select, y la lista de opciones que se abre debajo. El calendario que invoca un campo de fecha. La marca de la casilla de verificación. La barra de desplazamiento dentro de un textarea largo. Los botones de borrar y los ojos para mostrar la contraseña que algunos navegadores añaden por su cuenta. Eso lo pintan el navegador y el sistema operativo, con su propia paleta.
Y esa paleta trae un supuesto por defecto: la página es clara. Así que el navegador dibuja su flecha gris oscura, seguro de que contrastará bien con el fondo blanco que usted no tiene. La lista de opciones se abre como un panel blanco saliendo de su select color medianoche. El calendario llega como una linterna. Nada de esto es un error de renderizado. El navegador está respondiendo a una pregunta que su página nunca respondió: ¿sobre qué clase de fondo estoy?
Responda la pregunta: color-scheme
La respuesta es una declaración de CSS: color-scheme. Póngala en dark en una página oscura y el navegador repinta su mitad de cada control para que coincida. La flecha se aclara, la lista de opciones se oscurece, el calendario y las barras de desplazamiento la siguen. Hace más por carácter que casi cualquier otra cosa del CSS de un tema oscuro, y está entre las líneas que más a menudo faltan, porque sin ella todo se ve bien en la única máquina donde se construyó el tema.
Acótela con honestidad. Un sitio completamente oscuro la declara en la raíz. Un sitio claro con un pie de página oscuro la declara solo en el pie, ya que la propiedad aplica donde la ponga, y el navegador renderizará entonces controles claros en la mitad clara de la página y controles oscuros en la mitad oscura. La declaración es una afirmación de hecho sobre sus fondos. Hágala en todos los sitios donde el hecho sea cierto y en ninguno donde no lo sea.
Los restos que siguen siendo suyos
El autocompletado es el resto más afilado. Los navegadores inundan un campo rellenado con su propio color de resaltado, un amarillo pálido o un azul pálido ajustado para páginas claras, y guardan ese color con celo. Su texto blanco de formulario sobre esa inundación pálida es ilegible, y le ocurre precisamente a sus visitantes más eficientes: aquellos cuyo navegador ya conocía todas las respuestas. Hay escapes en CSS para ello. El punto real es que nadie los aplica a un problema que no ha visto ocurrir, así que autocomplete su propio formulario oscuro y mire.
Dos restos más discretos. El texto de los placeholders se renderiza en un gris ajustado contra el blanco, y sobre un fondo oscuro puede caer por debajo del mínimo de contraste que fijan las normas de accesibilidad, así que mídalo como cualquier otro texto (y manténgalo como pista y no como etiqueta, según lo dicho antes en esta serie).
Y el anillo de foco del teclado, que tenía contraste garantizado sobre blanco, puede desaparecer por completo sobre oscuro. Un usuario de teclado que recorre un formulario oscuro con un indicador de foco invisible está perdido de una forma que ningún usuario de ratón reproducirá jamás. Un estilo de foco personalizado visible se entrega con el tema, no después de la queja.
Una advertencia sobre la solución tentadora. Eliminar por completo la apariencia nativa y reconstruir el control compra autoridad visual total al precio de una obligación de por vida: ahora usted debe la flecha, los estados y su contraste en cada sistema operativo, para siempre. Y un select reconstruido con divs estilizados renuncia al comportamiento de teclado y a la semántica para lectores de pantalla que el control nativo traía gratis. Restilice primero el control nativo. Reconstruya solo cuando un requisito real lo obligue, y un color no es un requisito real.
Pruebe en la máquina que no posee
La auditoría aquí es una matriz, no un vistazo: el otro sistema operativo, sus modos claro y oscuro (los controles nativos siguen el humor del sistema además de su CSS), una pasada solo con teclado, una pasada con autocompletado. Veinte minutos, la mayoría pidiendo prestada la portátil de un colega. Los errores de este artículo viven exclusivamente en las combinaciones que su equipo no usa personalmente, que es exactamente cómo se publicaron.
Lo siguiente en la serie: la otra cosa que atraen los formularios además de visitantes. Frenar el spam sin un CAPTCHA, o cómo rechazar a los bots sin interrogar primero a cada humano.