Cómo crear un área de texto multilínea en HTML y usarla bien

Para que una persona pueda escribir varias líneas en un formulario web, el elemento adecuado es textarea. A diferencia de un campo de texto corriente, admite mensajes extensos, descripciones y comentarios con saltos de línea, sin trucos ni componentes adicionales. La etiqueta ya proporciona ese comportamiento; el trabajo consiste en integrarla correctamente para que el contenido pueda identificarse, enviarse y leerse con comodidad.

Una caja multilínea funcional necesita algo más que su forma rectangular. Debe contar con un nombre para transmitir su contenido al formulario, una etiqueta visible que explique qué se espera, un tamaño inicial razonable y estilos que encajen con la página. También importa qué ocurre después: los saltos que la persona introduce no siempre se muestran automáticamente al presentar el texto en otra parte del sitio. La estructura, la experiencia de uso y la gestión posterior forman parte de la misma solución.

La etiqueta que permite escribir en varias líneas

La estructura básica es breve: se abre el elemento, se indica un nombre para el dato y se define cuántas filas aparecerán al cargar la página. Por ejemplo, <textarea name=mensaje rows=6></textarea> crea una caja donde se puede escribir en varias líneas. No hace falta añadir una etiqueta de cierre especial ni recurrir a un input ensanchado con CSS: textarea está diseñado específicamente para texto de varias líneas.

El atributo rows controla la altura inicial aproximada, no la cantidad máxima de líneas que se pueden escribir. Con rows=6, el usuario ve un espacio de unas seis filas, pero puede seguir escribiendo y el campo mostrará barras de desplazamiento cuando haga falta. La anchura también puede expresarse con cols, aunque en diseños actuales suele resultar más práctico ajustar el ancho mediante CSS para que se adapte al contenedor y a la pantalla.

Un input type=text puede ocupar mucho espacio horizontal y parecer una caja grande, pero sigue siendo un control de una sola línea. Su propósito es recoger datos breves, como un nombre o un asunto; no se convierte en un campo multilínea por cambiar su tamaño visual. Si el contenido debe admitir párrafos y retornos de carro, textarea es la opción nativa. Para una edición de texto enriquecido con formatos, imágenes o enlaces, en cambio, puede hacer falta un editor especializado: no es lo mismo texto sin formato que un documento editable.

Una estructura completa y accesible

En un formulario real, la caja debería tener una etiqueta visible asociada. El atributo for del label debe coincidir con el id del área de texto; así, al seleccionar el nombre del campo, el foco se desplaza a la caja. Esta relación también aporta contexto a las tecnologías de asistencia y hace más sencillo reconocer el control cuando el formulario contiene varios campos parecidos. El texto que identifica el campo no debería depender solo de una pista temporal.

<label for=comentario>Comentario</label> <textarea id=comentario name=comentario rows=6 placeholder=Escribe-aquí-tu-mensaje></textarea>

El placeholder puede ofrecer una indicación breve, como el tipo de información que conviene incluir, pero desaparece cuando empieza la escritura. Por eso no reemplaza al label, ni es buen lugar para concentrar instrucciones largas, condiciones o avisos importantes. Si el usuario necesita más orientación, un texto visible junto al control resulta más fiable. La etiqueta da identidad al campo; la pista solo lo complementa.

El atributo name cumple otra función: identifica el dato cuando se envía el formulario. Sin él, el campo puede verse y permitir escribir, pero su contenido no se incluirá entre los datos enviados como se espera. El id, por su parte, permite asociar la etiqueta y localizar el elemento en CSS o JavaScript; ambos atributos pueden compartir valor, aunque responden a necesidades distintas. También conviene incluir el control dentro de un elemento form si debe formar parte de un envío convencional.

Texto inicial, límites y envío del formulario

El contenido inicial de un área de texto se escribe entre sus etiquetas de apertura y cierre, no en un atributo value. Por ejemplo, <textarea name=descripcion rows=5>Texto que se puede editar</textarea> muestra ese texto dentro del control. Es útil en un formulario de edición que carga información guardada; en un formulario nuevo, puede obligar a borrar palabras antes de comenzar. El valor precargado debe tener una razón funcional, no estar ahí para decorar el campo.

La indentación del código también puede tener efectos visibles cuando se incluye contenido entre las etiquetas. Los espacios y saltos de línea que se dejan junto al texto inicial pueden formar parte de lo que se presenta en la caja. Si aparece un espacio en blanco inesperado al principio o al final, merece la pena revisar el marcado antes de buscar un fallo en CSS. En una plantilla dinámica, además, conviene comprobar qué contenido se inserta y cómo se escapa para que los caracteres se interpreten como texto.

Los atributos de validación nativa permiten expresar condiciones sencillas. required marca el campo como obligatorio; maxlength establece un máximo de caracteres y minlength fija una longitud mínima. Por ejemplo, <textarea id=resena name=resena rows=7 maxlength=500 required></textarea> pide un contenido y limita su longitud máxima. Estas reglas ayudan en el navegador, pero no sustituyen la comprobación de los datos en el servidor, que debe validar lo recibido independientemente de lo que haya ocurrido en la página.

Si el formulario usa method=post, el contenido se envía en el cuerpo de la solicitud; con method=get, los datos se incorporan a la dirección web. Esa diferencia afecta a cómo viaja la información, pero POST no convierte por sí solo un envío en seguro ni cifra los datos. La protección de la conexión y el tratamiento posterior dependen de otros elementos de la aplicación. Para que el campo llegue al destino previsto, también deben estar bien configurados el formulario, su destino y el procesamiento del lado del servidor.

Cómo ajustar el aspecto con CSS

HTML proporciona la función; CSS permite que la caja tenga una anchura flexible, espacio interior suficiente y una tipografía coherente con el resto de la interfaz. Un ejemplo sencillo es .campo-largo { width: 100%; min-height: 160px; padding: 12px 14px; font: inherit; line-height: 1.5; border: 1px solid #b8b8b8; border-radius: 8px; box-sizing: border-box; resize: vertical; }. La combinación de una anchura adaptable y una altura mínima legible suele ser un buen punto de partida, aunque los valores concretos dependen del diseño y del tipo de texto solicitado.

width: 100% hace que el control ocupe el ancho disponible en su contenedor. Con box-sizing: border-box, el relleno y el borde se cuentan dentro de ese ancho, lo que evita que el elemento sobresalga por unos píxeles. font: inherit toma la tipografía definida para el entorno, mientras que line-height regula el espacio entre líneas. Son ajustes modestos, pero juntos evitan que el campo parezca una pieza ajena al formulario.

La altura visible debe guardar relación con lo que se pide. Un comentario breve no necesita el mismo espacio de partida que una incidencia técnica o una descripción detallada. Una caja diminuta puede transmitir que se espera una respuesta corta; una enorme puede ocupar una parte desproporcionada de la pantalla. No hay una cifra universal para rows o min-height: el tamaño adecuado depende de cuánto contenido se espera y del espacio disponible, en especial en móviles.

El foco también tiene que verse. Cuando una persona llega al campo con el teclado, un cambio perceptible en el borde o el contorno permite reconocer dónde está escribiendo. Si se personaliza el estilo de foco, no conviene eliminar el indicador del navegador sin ofrecer una alternativa igual de clara. Un diseño sobrio puede conservarlo así: .campo-largo:focus-visible { outline: 2px solid #333; outline-offset: 2px; }. El acabado visual debe hacer la interacción más comprensible, no ocultarla.

Redimensionado y crecimiento automático

En muchos navegadores, el usuario puede arrastrar la esquina de una textarea para cambiar su tamaño. El CSS resize permite decidir si se puede modificar en ambas direcciones, solo verticalmente o en ninguna. resize: vertical suele mantener el ancho alineado con el diseño y permitir que la caja crezca hacia abajo; resize: none impide cambiar sus dimensiones. Bloquear el ajuste puede ser apropiado en una composición muy controlada, pero también puede dejar al usuario con poco espacio si el texto se alarga.

Otra posibilidad es aumentar automáticamente la altura a medida que se escribe. Para un campo que empieza con pocas líneas y puede terminar conteniendo varios párrafos, ese comportamiento evita que el texto quede oculto tras una barra de desplazamiento interna. Se puede implementar con JavaScript midiendo la altura necesaria después de cada cambio: const area = document.querySelector('#nota'); area.addEventListener('input', () => { area.style.height = 'auto'; area.style.height = `${area.scrollHeight}px`; });. El ajuste automático es una mejora opcional, no un requisito para que el campo sea multilínea.

Antes de añadirlo, conviene pensar en el efecto sobre el resto de la página. Si la caja puede crecer mucho, empujará los controles posteriores y alargará el formulario; en una ventana estrecha, un texto extenso puede desplazar contenido importante fuera de la vista. También hay que probar qué ocurre cuando se carga texto de antemano, se cambia el tamaño de la ventana o el navegador restaura un formulario. En muchos casos, una altura inicial suficiente y el redimensionado vertical ofrecen una solución más simple y previsible.

Los saltos de línea no se comportan igual en todos los sitios

Dentro de una textarea, al pulsar Enter se introduce un salto de línea en el texto. Eso forma parte del valor que el usuario escribe. Sin embargo, un salto en el código fuente HTML no siempre se traduce en un salto visible al mostrar texto corriente en una página: el navegador suele tratar los espacios consecutivos y los retornos del HTML según las reglas habituales de presentación. Que el campo conserve varias líneas no garantiza que otra parte de la web las muestre del mismo modo.

Si el texto guardado debe presentarse respetando los saltos y los espacios escritos, puede aplicarse white-space: pre-wrap al elemento que lo muestra: .texto-publicado { white-space: pre-wrap; }. Esta regla conserva los espacios y los retornos de línea, a la vez que permite que las líneas largas se ajusten al ancho disponible. Es útil para comentarios o mensajes sin formato, aunque la apariencia final sigue dependiendo de los estilos y del contexto en que se presenta.

La etiqueta <br> sirve para forzar un salto de línea dentro del contenido HTML, pero no es una alternativa a textarea para que el usuario escriba. Del mismo modo, dos párrafos separados semánticamente suelen representarse con elementos de párrafo, no acumulando saltos manuales. Un retorno escrito por el usuario, un salto de línea visual y un párrafo HTML son conceptos relacionados, pero no intercambiables. Distinguirlos ayuda a evitar resultados en los que el contenido aparece aplastado o con espacios excesivos.

Al mostrar en una página el texto recibido, la aplicación también debe tratarlo como contenido no confiable. El valor de una textarea es texto introducido por el usuario y no debería convertirse directamente en HTML ejecutable. Si se necesita conservar el formato de línea, hay que hacerlo con una salida segura y estilos apropiados, sin interpretar etiquetas aportadas por quien escribe. Respetar el formato no implica confiar en el contenido; la validación y el escape deben formar parte del procesamiento de la aplicación.

Atributos menos visibles y diferencias importantes

El atributo wrap afecta a cómo se ajustan las líneas del texto durante el envío del formulario. El comportamiento habitual, soft, permite que las líneas largas se ajusten visualmente sin añadir por ello saltos duros equivalentes en el valor enviado. hard puede incluir saltos en el texto transmitido según las condiciones del control y el navegador, y requiere especificar cols. Como su efecto puede importar en sistemas que procesan texto plano de una forma concreta, no es un ajuste estético: afecta a la representación del contenido enviado.

También hay una diferencia entre readonly y disabled. Con readonly, el contenido se puede leer y normalmente seleccionar, pero no modificar; el campo puede seguir participando en el envío. Con disabled, el control queda inactivo y, en un envío convencional, sus datos no se incluyen. La elección importa cuando se muestra información que el usuario debe revisar o copiar, pero no cambiar. Dos controles que parecen bloqueados pueden comportarse de manera distinta al enviar el formulario.

El elemento puede conectarse a un formulario incluso si no está dentro de él mediante el atributo form, siempre que se indique el id correspondiente del formulario. En la mayoría de los casos, sin embargo, mantener el campo dentro de la estructura del formulario hace el marcado más fácil de entender y mantener. JavaScript puede añadir contadores, mensajes de estado o validaciones en tiempo real, pero esos añadidos deberían complementar el comportamiento nativo y no ser la única forma de identificar errores o de completar la tarea.

Errores que suelen estropear un campo bien planteado

El primer error es utilizar un input para una respuesta que necesita varias líneas. El campo puede ampliarse visualmente, pero no adquiere la edición multilineal propia de textarea. Otro descuido es olvidar name: la caja funciona a la vista, aunque su contenido no se identifique correctamente en el envío. La prueba no consiste solo en comprobar que se puede escribir; también hay que verificar qué dato recibe el formulario.

Un placeholder largo suele intentar resolver a la vez la identificación, las instrucciones y las condiciones de respuesta. Al comenzar a escribir desaparece, así que la persona puede perder el contexto. Una etiqueta breve y visible, acompañada de instrucciones fuera del campo cuando sean necesarias, da una referencia más estable. También conviene revisar la legibilidad en móvil: un control estrecho, con poco espacio interior o líneas demasiado apretadas puede resultar incómodo incluso si el HTML es correcto.

Otro fallo aparece después del envío, cuando los saltos escritos desaparecen al mostrar el contenido. En ese caso, no hay que añadir etiquetas <br> al formulario por defecto: primero hay que decidir cómo debe presentarse el texto y aplicar el tratamiento correspondiente, como white-space: pre-wrap para texto plano. Tampoco es buena idea aceptar que el usuario cambie el tamaño en cualquier dirección sin comprobar si eso rompe la composición. La experiencia incluye tanto la escritura como la lectura posterior.

Una base sencilla que resuelve lo esencial

Un ejemplo completo puede mantener una estructura directa: <form action=/enviar method=post> <label for=descripcion>Descripción</label> <textarea id=descripcion name=descripcion rows=8 maxlength=1000 required></textarea> <button type=submit>Enviar</button> </form>. En una implementación real, el formulario debe conectarse al destino que procese los datos y el campo puede recibir una clase CSS para adaptar su aspecto. La etiqueta, la asociación con su nombre y el atributo name cubren tres necesidades distintas: permitir la escritura, identificar el control y enviar su contenido.

El máximo de caracteres del ejemplo es una decisión ilustrativa, no una medida válida para cualquier formulario. El límite debería responder a lo que la aplicación puede recibir y almacenar, y el usuario debe poder entenderlo cuando condiciona su respuesta. Si se añade un contador con JavaScript, su estado también debe ser accesible y actualizarse de forma clara; la validación del servidor sigue siendo necesaria. Los atributos nativos facilitan la interacción, pero no reemplazan el diseño ni el procesamiento de los datos.

Crear un campo de varias líneas en HTML es sencillo; diseñarlo para que funcione de principio a fin exige atender a detalles que a menudo quedan fuera de la primera prueba. El tamaño inicial orienta, el etiquetado aporta contexto, el CSS mejora la lectura y la presentación posterior determina si se conserva la estructura escrita. Cuando esos elementos trabajan juntos, textarea deja de ser un rectángulo añadido al formulario y se convierte en un control claro, accesible y preparado para recibir texto real.