Editar el DOM en vivo sin engañarte
Las seis operaciones de edición del árbol, qué le hacen realmente a la página, y el uso correcto de la edición como herramienta de hipótesis en lugar de como arreglo.
El panel de Elements deja modificar el árbol: cambiar atributos, reescribir marcado entero, mover nodos, ocultarlos, borrarlos. Es rápido, es satisfactorio y es la puerta a un mal hábito muy extendido, que consiste en toquetear hasta que la pantalla se ve bien y luego intentar reproducir en el código lo que se hizo a mano. Usada al revés —para comprobar una hipótesis concreta y volver atrás— la misma capacidad es una de las formas más rápidas de acotar un problema visual.
- Ejecutar las seis operaciones de edición del árbol y saber qué modifica cada una.
- Distinguir la edición como experimento de la edición como arreglo, y por qué la segunda no existe.
- Recuperarse de una edición equivocada y saber qué se puede deshacer y qué no.
- Diseñar experimentos de una sola variable con las herramientas de edición.
Las seis operaciones
Editar un atributo. Doble clic sobre el nombre o el valor, o la tecla de entrada con el nodo seleccionado. El tabulador salta al siguiente. Es la operación más frecuente y la más inofensiva, con una excepción: editar el atributo class de un componente reactivo casi nunca sirve, porque el siguiente render lo sobrescribe.
Editar como HTML. Convierte el nodo entero en un campo de texto editable con su marcado externo. Al confirmar, el navegador reparsea esa cadena y sustituye el subárbol. Dos consecuencias importantes: los listeners de eventos registrados por JavaScript sobre los nodos antiguos se pierden, porque los nodos son nuevos; y el marcado que escribas pasa por el mismo algoritmo de corrección de errores que el documento original, así que puede no quedar como lo escribiste.
Añadir un atributo. Desde el menú contextual, o pulsando la tecla de entrada al final de la lista de atributos existentes.
Mover un nodo. Arrastrando en el árbol, o con las opciones del menú contextual para moverlo arriba y abajo entre hermanos. Es un insertBefore de verdad: el nodo es el mismo objeto, así que conserva sus listeners y su estado. Esa diferencia con la edición como HTML importa: mover un input no le borra lo que el usuario había escrito, reescribirlo como HTML sí.
Ocultar un nodo. La tecla H con el nodo seleccionado. No lo borra: le aplica visibility: hidden mediante una regla interna. Es reversible con la misma tecla, y el nodo sigue ocupando su espacio en el layout, lo cual es a veces lo que quieres y a veces exactamente lo contrario.
Borrar un nodo. La tecla de suprimir, o la opción del menú contextual. Sí es destructivo, y sí se puede deshacer con Cmd+Z o Ctrl+Z mientras el foco esté en el árbol.
Deshacer funciona sobre las ediciones del panel, no sobre lo que la página haya hecho como reacción. Si borras un nodo y un MutationObserver de la aplicación reacciona cerrando un menú y reseteando un estado, deshacer devuelve el nodo pero no el estado. En una aplicación con lógica reactiva, la recarga es más fiable que el deshacer.
Editar como experimento, no como arreglo
La distinción que ordena toda la lección. Editar el DOM en el panel no cambia tu código, no persiste y no es reproducible. Por tanto no es un arreglo. Lo que sí es, y muy bueno, es un mecanismo de contraste de hipótesis con ciclo de iteración de un segundo, frente a los quince o treinta segundos que cuesta editar el fichero, guardar, esperar la recompilación y recargar.
La forma correcta de usarlo tiene tres reglas.
Una variable por experimento. Si quitas un overflow: hidden y a la vez cambias un position, y la cosa se arregla, no sabes cuál de las dos era. Con ciclos de un segundo no hay ninguna excusa para agrupar cambios.
Verbaliza la hipótesis antes de tocar. “Creo que este contenedor está recortando el menú” es una hipótesis; el experimento es quitar el overflow y mirar. “A ver si con esto” no es nada.
Vuelve atrás siempre. Deshaz o recarga después de cada experimento, exitoso o no. El estado acumulado de quince ediciones es un entorno que no existe en ninguna parte y donde ninguna conclusión es válida.
Los cuatro experimentos que más rinden
Hay un puñado de ediciones que responden preguntas muy frecuentes, y merece la pena tenerlas como reflejo.
Ocultar para localizar. Un elemento tapa a otro y no sabes cuál es. Selecciona candidatos y pulsa H hasta que el problema desaparezca. Es bisección visual pura y encuentra al culpable en cuatro o cinco pulsaciones sobre un árbol de cientos de nodos.
Borrar para medir el impacto. Sospechas que un widget concreto es el que hace lenta la página. Bórralo del árbol y observa. No es una medición rigurosa, pero descarta o confirma en cinco segundos si merece la pena montar una medición rigurosa.
Mover para diagnosticar el contexto. Un elemento posicionado se comporta raro. Arrástralo fuera de su contenedor actual, al body. Si al salir se comporta bien, el problema está en algún ancestro: un transform, un filter, un contain o un overflow que está creando un contexto que no esperabas.
Duplicar para comparar. La opción de duplicar elemento crea una copia hermana. Modificando la copia y dejando el original intacto tienes las dos versiones lado a lado en la misma página, con la misma cascada y el mismo contexto. Para diferencias visuales sutiles es mucho mejor que alternar entre dos estados.
Hay una trampa en la edición en vivo que produce falsos positivos con una regularidad deprimente, y conviene reconocerla porque cuesta horas cuando llega a producción. Cuando editas un nodo desde el panel, el navegador recalcula el layout con el estado actual de la página, no con el estado inicial. Si el bug depende del orden en que ocurrieron las cosas —una animación que ya terminó, un ResizeObserver que ya se disparó, un valor que un script leyó y cacheó al cargar, una fuente que ya se descargó y sustituyó a la de reserva— tu edición se aplica sobre un mundo donde esos eventos ya pasaron, y en producción tu arreglo se aplicaría sobre un mundo donde todavía no. El síntoma clásico: cambias un valor en el panel, la página se ve perfecta, escribes el mismo cambio en el CSS, recargas, y el bug sigue ahí exactamente igual. No estás loco y el panel no miente: es que la condición inicial es distinta. La comprobación que lo resuelve es siempre la misma y no hay atajo: cuando un experimento en vivo dé resultado positivo, escríbelo en el código y verifícalo con una recarga limpia antes de darlo por bueno. El panel sirve para generar candidatos rápido; la recarga es la única que valida. Y si el arreglo funciona en el panel y falla tras recargar, ya tienes una pista valiosísima: tu bug depende del orden temporal, y eso te manda directo a Sources con una hipótesis mucho más concreta que la que tenías.
Lo que la edición no puede tocar
Conviene saber dónde se acaba el juguete. No puedes editar los pseudo-elementos como nodos, porque no lo son; sus estilos sí se editan desde el panel de estilos. No puedes editar el shadow DOM cerrado. No puedes editar la estructura interna del shadow DOM del agente de usuario de los controles nativos, aunque puedas verla. Y aunque puedas editar el marcado dentro de un iframe de otro origen a través del panel, no puedes acceder a él desde la consola, porque esa restricción es del modelo de seguridad y no de la herramienta.
Cuando el experimento que quieres hacer choca con alguno de esos límites, la vía suele ser la consola con las utilidades adecuadas o, para casos persistentes, los overrides locales.