# WordPress 7.1 quiere estilos responsive nativos y lleva años tarde: lo que no te cuentan
**Categoría:** CMS
**Estilo:** crítico
**Slug:** wordpress-7-1-estilos-responsive-tarde
—
La beta 1 de WordPress 7.1 llega el 15 de julio y, por fin, el núcleo quiere que edites estilos distintos para móvil y tablet sin escribir CSS a mano. Suena bien. Demasiado bien para quien lleva una década viendo cómo Elementor, Bricks o incluso el viejo Divi resolvieron eso hace años mientras Gutenberg seguía prometiendo que «pronto».
El call for testing publicado el 3 de julio pide probar el PR #75121: un modo de edición responsive que unifica el canvas redimensionable con el selector de dispositivos. Activas «Responsive editing», cambias a tablet, ajustas el tamaño de fuente de un heading y ese cambio debería quedarse solo en ese viewport. En papel, es lo mínimo que cualquier constructor visual ofrece desde 2016.
Lo que me chirría no es la funcionalidad en sí —bienvenida sea— sino el calendario. El roadmap de 7.1 lo presenta como «un gran paso» hacia algo que la comunidad pedía desde la era del Site Editor. Joen Asmussen, que ha diseñado buena parte de la experiencia de bloques, todavía debatía en julio si al elegir un breakpoint distinto de desktop debería activarse automáticamente el modo responsive o haría falta un toggle aparte. Eso no es un detalle cosmético: es la diferencia entre una herramienta intuitiva y otra que obliga a leer documentación antes de maquetar una landing sencilla.
Si gestionas webs para clientes, ya sabes cómo acaba esto. Llevas años metiendo media query en el CSS del tema hijo, o pagando licencia de un page builder porque el cliente necesita ver cómo queda el botón en el iPhone sin llamarte un domingo. WordPress core te vendía la promesa de unificar diseño y contenido en un solo editor. Pero mientras tanto, los plugins de terceros facturaban millones cubriendo un hueco que el proyecto oficial no priorizaba. No es casualidad: Automattic tiene intereses en ambos lados del tablero, y un core demasiado completo resta argumentos de venta a soluciones premium del ecosistema. Digo esto sin conspiración barata; es economía de producto.
El propio roadmap reconoce que los estilos responsive llegarán tanto a estilos globales como a instancias concretas de bloque, apoyándose en el mismo mecanismo de «style states» que ya usa hover y focus. Bien. Pero fíjate en lo que no dicen con la misma claridad: qué pasa con temas clásicos que no usan theme.json, qué compatibilidad real tendrán plugins que manipulan el canvas del editor, y si los breakpoints por defecto (480px móvil, 782px tablet) encajan con el tráfico real de tus clientes —muchas tiendas WooCommerce siguen viendo picos en viewports intermedios que esos números ignoran.
Tampoco ayuda el ritmo de releases. La programación oficial fija el lanzamiento final para el 19 de agosto de 2026, con betas cada semana a partir del 15 de julio. Eso deja pocas semanas para pulir una feature que lleva años en el tintero. Los contribuidores piden feedback sobre si los cambios por viewport sobreviven al guardar y recargar, si los handles de resize y el dropdown van sincronizados, y si la UX se siente natural. Traducción: todavía no está claro que funcione de forma fiable en producción cuando lo subas a un site con veinte plugins activos.
En mi experiencia, cada gran novedad del Site Editor llega a medias. Recuerdas las notas colaborativas, la colaboración en tiempo real, las guidelines editoriales… todo en el roadmap, todo «avanzando». El responsive styling es más tangible que esas promesas etéreas, pero cae en el mismo patrón: anuncio optimista, testing comunitario de última hora, y luego tres versiones menores corrigiendo regresiones que descubren las agencias, no los release parties.
¿Significa que debas ignorar 7.1? No. Si estás planteando migrar de un page builder a core nativo, esta release puede ser el empujón que necesitabas —siempre que tus proyectos sean relativamente simples y no dependan de animaciones complejas o condicionales por rol. Para tiendas con checkout personalizado, memberships o funnels montados en Elementor Pro, quitar el builder porque WordPress ahora deja cambiar el padding en tablet suena a ahorro ficticio: el coste de rehacer plantillas lo pagas tú, no Matt Mullenweg.
Lo sensato, creo yo, es probar en staging con Playground o una beta en un entorno desechable —exactamente lo que pide el equipo de test— y medir cuántas horas reales te ahorra frente a tu flujo actual. Si el ahorro es cero porque acabas exportando CSS igualmente, la narrativa de «por fin en core» se queda en marketing.
Y aquí está la pregunta incómoda: si mañana tu cliente te pidiera dejar Elementor y montar la misma home solo con Gutenberg 7.1, ¿cuántas horas extra le facturarías por compensar funciones que el core todavía no cubre, o le dirías que espere a 7.2 como llevamos haciendo desde 2022?