Resumen

  • datalist ofrece valores sugeridos a un input mediante el atributo list, mientras el campo sigue siendo editable.
  • El navegador decide cómo mostrar y filtrar la lista; la persona conserva la posibilidad de introducir otro valor válido.

Hay formularios que parecen un funcionario con sello: «Elija una de estas opciones; su caso particular puede esperar». Otros se comportan como alguien que acerca una hoja con respuestas frecuentes y deja el bolígrafo sobre la mesa. datalist permitió esa segunda escena. El autor prepara pistas, el navegador las acerca al campo de entrada, y quien responde puede seguir escribiendo. El formulario tiene memoria de lo habitual, pero no hace de portero de lo inesperado.

El primer borrador público del lenguaje de marcado HTML del W3C, de marzo de 2010 marcaba datalist como elemento nuevo. Lo definía como conjunto de opciones predefinidas para otros controles y contemplaba contenido de respaldo para navegadores antiguos. La pequeña precaución conserva el olor de aquella época: la Web renovaba sus formularios mientras millones de páginas seguían hablando con programas de generaciones distintas.

La referencia del W3C de 2011 mantuvo la idea de opciones para otros controles. Esa separación es el mecanismo: datalist guarda las propuestas y input recoge la respuesta. El autor puede ordenar una colección de posibilidades sin apropiarse del teclado de la persona. La lista recomienda los caminos transitados; el campo admite que alguien viva en una calle que el mapa del formulario todavía no conoce.

El estándar HTML actual, en su sección de formularios, precisa que una option habilitada con valor no vacío representa una sugerencia. La sugerencia puede tener valor y etiqueta. Un input enlaza con el datalist cuyo identificador nombra en list. La etiqueta ayuda a reconocer el elemento en pantalla; al elegirlo, el valor pasa al campo. La diferencia permite hablar de modo natural a la persona y conservar un dato estable para el sistema.

Las reglas del campo de entrada dan al navegador un papel activo. Debe ofrecer sugerencias durante la edición y puede filtrar conjuntos grandes. La búsqueda recomendada mira etiquetas y valores, con normalización Unicode y cuidado ante variantes de mayúsculas. Parece una precisión de laboratorio, pero evita que dos maneras de teclear un mismo nombre aparten al usuario de la respuesta que tenía delante. La ayuda tiene que seguir la mano de quien escribe.

Si se escoge una sugerencia, el navegador coloca su valor como si lo hubiese tecleado la persona. Si se escribe otra entrada aceptable, se usa el mismo campo. El tipo de input y sus restricciones normales siguen decidiendo la validez. Una lista de destinos puede acelerar la elección de una ciudad conocida y dejar pasar una localidad que el editor no había previsto. Ofrecer atajos no exige cerrar el camino.

La negociación es sorprendentemente civilizada: el autor propone, el navegador organiza, la persona responde. Los menús cerrados tienen su lugar cuando el universo de opciones es finito. Las preguntas sobre la vida real suelen traer respuestas que faltaban en la reunión donde se diseñó el formulario. datalist no escribe esa octava respuesta. Deja el bolígrafo donde siempre debió estar.