Buenas prácticas para crear y mantener bloques personalizados y complejos en Waclis

El Editor de bloques de Waclis permite crear desde composiciones sencillas hasta secciones completamente personalizadas mediante:

• Secciones prediseñadas;

• Componentes;

• Grid Row y columnas;

• Contenido;

• Estilo;

• Avanzado;

• Navigator;

• Classes e IDs;

• CSS;

• HTML;

• JavaScript en desarrollos que lo requieran;

• herramientas de inteligencia artificial como ChatGPT, Claude o Gemini.

A medida que un bloque se vuelve más complejo, también aumenta la importancia de mantenerlo:

• organizado;

• responsive;

• fácil de identificar;

• aislado del resto de la Página web;

• sencillo de modificar posteriormente.

Este tutorial reúne las principales buenas prácticas para construir bloques avanzados sin perder el control sobre su estructura.

¿Qué consideramos un bloque complejo?

No existe una cantidad exacta de elementos que transforme un bloque en complejo.

En general, podemos considerar avanzado un bloque cuando combina varias de estas características:

• varias filas y columnas;

• numerosos elementos anidados;

• HTML personalizado;

• CSS propio;

• Hover o transiciones;

• media queries;

• animaciones;

• JavaScript;

• contenido incrustado;

• componentes externos;

• diferentes comportamientos responsive;

• varias Classes e IDs;

• estilos compartidos;

• contenido generado o modificado mediante IA.

Por ejemplo:

Section
├── Container
│   ├── Heading
│   ├── Paragraph
│   └── Grid Row
│       ├── Grid Column
│       │   └── Card
│       │       ├── Image
│       │       ├── Heading
│       │       ├── Paragraph
│       │       └── Button
│       │
│       ├── Grid Column
│       │   └── Card
│       │       └── ...
│       │
│       └── Grid Column
│           └── Card
│               └── ...
│
└── CTA

Esto continúa siendo perfectamente administrable si la estructura mantiene una lógica clara.

La complejidad no es un problema si está organizada

Una sección puede contener:

• HTML;

• CSS;

• varias tarjetas;

• responsive;

• Hover;

• animaciones;

y seguir siendo fácil de mantener.

El problema aparece cuando no resulta sencillo responder preguntas como:

¿Qué Class controla las tarjetas?

¿Qué elemento contiene la imagen?

¿Dónde se cambia el responsive?

¿Este CSS afecta solo a esta sección?

¿Qué script utiliza esta Class?

¿Puedo clonar esta tarjeta sin romper algo?

La organización debe permitir responder estas preguntas con facilidad.

1. Define primero qué quieres construir

Antes de empezar a agregar componentes, piensa en el objetivo de la sección.

Por ejemplo:

Objetivo: presentar tres servicios y dirigir al visitante hacia Contacto.

Entonces puedes definir:

Título
↓
Texto introductorio
↓
3 tarjetas de servicios
↓
CTA

Esto es preferible a comenzar agregando componentes sin una estructura prevista.

Define también la distribución

Por ejemplo:

Desktop

[ Servicio 1 ] [ Servicio 2 ] [ Servicio 3 ]

Celular

[ Servicio 1 ]

[ Servicio 2 ]

[ Servicio 3 ]

Pensar desde el comienzo cómo deberá responder la sección ayuda a evitar correcciones innecesarias posteriormente.

2. Utiliza la herramienta más simple que resuelva la necesidad

No todo requiere HTML o CSS.

Puedes pensar en una progresión:

SECCIÓN PREDISEÑADA
        ↓
COMPONENTES
        ↓
CONTENIDO
        ↓
ESTILO
        ↓
AVANZADO
        ↓
HTML / CSS
        ↓
JAVASCRIPT

No significa que debas utilizar obligatoriamente todos estos niveles.

Significa que conviene evitar complejidad técnica cuando existe una solución más sencilla.

Ejemplo: cambiar un color

Si quieres cambiar el fondo de una Card:

Estilo → Background Color

suele ser suficiente.

No necesitas escribir CSS.

Ejemplo: efecto Hover avanzado

Si quieres que una Card se eleve suavemente:

.servicio-card {
    transition: transform .3s ease;
}

.servicio-card:hover {
    transform: translateY(-5px);
}

En este caso CSS puede ser apropiado porque necesitas un efecto más específico.

Ejemplo: comportamiento interactivo específico

Si necesitas una interacción que no puede resolverse mediante las herramientas visuales ni CSS, entonces puede tener sentido utilizar JavaScript.

La idea es:

utilizar la menor complejidad necesaria para conseguir el resultado.

3. Trabaja de afuera hacia adentro

Una estructura ordenada suele comenzar por los contenedores generales.

Por ejemplo:

Section
↓
Container
↓
Grid Row
↓
Grid Columns
↓
Componentes

Primero define:

• la sección;

• el ancho;

• la grilla;

• las columnas.

Después agrega:

• imágenes;

• títulos;

• textos;

• botones.

Ejemplo

Quieres:

[ IMAGEN ] [ TÍTULO + TEXTO + BOTÓN ]

Es preferible construir primero:

Section
└── Container
    └── Grid Row
        ├── Grid Column
        └── Grid Column

y después insertar el contenido.

Evita agregar elementos y acomodarlos después “a fuerza de espacios”

Por ejemplo, no es una buena estrategia utilizar:

Margin Left: 300px

para simular una segunda columna cuando puedes utilizar Grid Row.

Eso puede funcionar en una resolución concreta y fallar en otras.

4. Utiliza Navigator como herramienta de control

En bloques complejos, Navigator no debería utilizarse únicamente cuando aparece un problema.

También sirve para mantener la estructura ordenada mientras construyes.

Revisa periódicamente:

• Sections;

• Containers;

• Grid Rows;

• Grid Columns;

• Cards;

• Links;

• Images;

• componentes internos.

Ejemplo

Visualmente puedes ver:

[ IMAGEN ] [ TEXTO ]

pero Navigator podría mostrar:

Grid Row
├── Image
├── Grid Column
└── Paragraph

cuando realmente esperabas:

Grid Row
├── Grid Column
│   └── Image
│
└── Grid Column
    └── Paragraph

La segunda estructura será generalmente más fácil de adaptar y mantener.

5. Organiza por unidades visuales y funcionales

No necesitas convertir cada pequeño componente en una Section independiente.

Una sección de Servicios puede contener:

Section: Servicios
├── Heading
├── Paragraph
├── Grid Row
│   ├── Card
│   ├── Card
│   └── Card
└── Button

Esto forma una unidad lógica.

Evita fragmentar demasiado

Una estructura como:

Section → Heading

Section → Paragraph

Section → Card 1

Section → Card 2

Section → Card 3

Section → Button

puede resultar innecesariamente difícil de mantener si todos esos elementos forman parte de una misma composición.

Pero tampoco concentres toda la página en una única estructura

También evita:

Section
└── todo el contenido de la página
    └── decenas o cientos de elementos

sin una organización clara.

Es preferible dividir el contenido en unidades comprensibles:

Section: Presentación

Section: Beneficios

Section: Servicios

Section: Testimonios

Section: Preguntas frecuentes

Section: CTA

6. Utiliza Classes descriptivas

En bloques personalizados, las Classes son una de las mejores herramientas para mantener el código organizado.

Por ejemplo:

servicios-section
servicios-grid
servicio-card
servicio-icono
servicio-titulo
servicio-texto
servicio-boton

Estos nombres permiten comprender rápidamente qué representa cada elemento.

Evita nombres poco descriptivos

Por ejemplo:

caja1
caja2
nuevo
rojo
prueba
elemento4

Puede resultar difícil recordar posteriormente qué representan.

Nombra según la función

Es preferible:

servicio-card

que:

caja-blanca

Porque el diseño de la Card puede cambiar y dejar de ser blanca.

La función seguirá siendo:

tarjeta de servicio.

7. Utiliza un prefijo en secciones avanzadas

Si desarrollas un bloque muy personalizado, un prefijo ayuda a evitar conflictos.

Por ejemplo, para una grilla de categorías puedes utilizar:

catgrid-section
catgrid-wrap
catgrid-grid
catgrid-card
catgrid-image
catgrid-title

¿Por qué ayuda?

Porque reduces la posibilidad de coincidir con Classes utilizadas en otras partes.

Por ejemplo:

.card

es muy genérico.

En cambio:

.catgrid-card

describe una pieza concreta de tu composición.

8. Mantén una Class principal para delimitar la sección

Esta es una de las buenas prácticas más importantes cuando escribes CSS.

Por ejemplo:

class="servicios-section"

Luego puedes escribir:

.servicios-section .servicio-card {
    border-radius: 16px;
}

¿Por qué?

Porque esa regla queda limitada a las tarjetas dentro de Servicios.

En lugar de:

.card {
    border-radius: 16px;
}

que podría alcanzar otros componentes.

Piensa en el scope

Puedes imaginar:

.servicios-section
└── todo mi CSS debe intentar permanecer aquí

Esto ayuda especialmente en páginas que también tienen:

• catálogo;

• Blog;

• componentes prediseñados;

• otras secciones personalizadas;

• elementos de la plantilla.

9. Mantén los estilos compartidos cuando tengan sentido

Si tres Cards deben ser iguales:

Card 1
Card 2
Card 3

es lógico que compartan:

class="servicio-card"

No necesitas crear:

servicio-card-1
servicio-card-2
servicio-card-3

si todas deben tener la misma apariencia.

Aprovecha Linked styles

Cuando Waclis muestra:

Linked styles

no significa necesariamente que exista un problema.

Puede indicar que estás modificando justamente un estilo compartido.

Esto puede ser útil para mantener:

• mismas dimensiones;

• mismo fondo;

• mismo Padding;

• mismo Border radius;

• mismo Hover.

10. Crea excepciones sin destruir la regla general

Supongamos que tres tarjetas utilizan:

servicio-card

pero una debe destacar.

No necesitas quitarle la Class común.

Puedes agregar:

destacado

Resultado:

Card 1
class="servicio-card"

Card 2
class="servicio-card destacado"

Card 3
class="servicio-card"

CSS

.servicios-section .servicio-card {
    border: 1px solid #ddd;
}

.servicios-section .servicio-card.destacado {
    border-width: 3px;
}

La segunda Card mantiene la base común y agrega una excepción.

11. Utiliza IDs solamente cuando corresponda

Un ID debe identificar un elemento único.

Por ejemplo:

id="banner-principal"

o:

id="servicio-premium"

No es necesario asignar un ID a cada componente.

Utiliza ID cuando necesites

• un elemento único;

• un ancla;

• una referencia JavaScript;

• una personalización individual;

• una identificación muy específica.

Mantén cada ID único

Evita:

Card 1 → id="servicio"
Card 2 → id="servicio"
Card 3 → id="servicio"

12. Revisa IDs después de clonar

Clonar es una excelente manera de mantener consistencia.

Pero después de clonar una estructura comprueba:

• Classes;

• IDs;

• URLs;

• textos;

• imágenes.

Las Classes normalmente pueden mantenerse.

Los IDs individuales pueden necesitar ser modificados.

Ejemplo

Original:

id="servicio-diseno"

Copia:

id="servicio-desarrollo"

13. No elimines Classes existentes sin conocer su función

Un componente puede tener:

class="card col-sm-4 servicio-card"

Estas Classes pueden cumplir diferentes funciones.

Por ejemplo:

• card → apariencia o estructura;

• col-sm-4 → distribución responsive;

• servicio-card → personalización propia.

No reemplaces todo por

class="mi-card"

sin comprender qué estás eliminando.

Podrías perder:

• Grid;

• responsive;

• diseño;

• comportamiento.

Si necesitas una Class propia

Normalmente puedes agregarla:

class="card col-sm-4 servicio-card mi-personalizacion"

cuando corresponda.

14. Mantén HTML, CSS y JavaScript relacionados

En un bloque avanzado puedes tener:

HTML

<div class="producto-card">

CSS

.producto-card {
    border-radius: 16px;
}

JavaScript

document.querySelectorAll('.producto-card')

Los tres dependen de:

producto-card

Cuidado al renombrar

Si cambias en HTML:

producto-card

por:

producto-tarjeta

también debes comprobar si esa Class aparece en:

• CSS;

• JavaScript.

De lo contrario, alguna funcionalidad puede dejar de aplicarse.

15. No agregues JavaScript cuando CSS sea suficiente

Supongamos que quieres que una Card suba 5 píxeles en Hover.

CSS:

.servicio-card {
    transition: transform .3s ease;
}

.servicio-card:hover {
    transform: translateY(-5px);
}

es suficiente.

No necesitas crear un script para detectar:

• mouseenter;

• mouseleave;

• posición.

Utiliza JavaScript cuando realmente necesites comportamiento

Por ejemplo:

• interacciones especiales;

• lógica;

• manipulación de elementos;

• componentes personalizados;

• integraciones;

• comportamientos que CSS no puede realizar.

Menos JavaScript suele significar menos puntos de falla cuando el mismo resultado puede resolverse de forma más simple.

16. Evita selectores CSS excesivamente generales

Debes utilizar con mucho cuidado:

div {
}

img {
}

a {
}

h2 {
}

.card {
}

porque pueden afectar componentes que no pertenecen a tu bloque.

Mejor

.servicios-section .servicio-card {
}

Mejor aún si necesitas algo concreto

.servicios-section .servicio-card .servicio-titulo {
}

Siempre que el nivel adicional sea realmente necesario.

17. Evita selectores excesivamente complejos

Tampoco es conveniente caer en el extremo contrario.

Por ejemplo:

body .main .page .section .container .row .col .card .wrapper h3 span {
}

puede resultar muy difícil de mantener.

Una Class específica como:

.servicio-titulo {
}

puede ser mucho más clara.

18. Utiliza CSS visual antes de !important

Cuando una regla no se aplica, puede ser tentador escribir:

color: red !important;

Pero primero revisa:

• Class;

• ID;

• selector;

• scope;

• especificidad;

• reglas existentes;

• Linked styles.

!important puede utilizarse en situaciones concretas, pero no debería convertirse en la solución automática para cualquier conflicto.

19. Mantén juntas las reglas relacionadas

Supongamos que trabajas con Servicios.

Es más fácil mantener:

/* Servicios */

.servicios-section {
}

.servicios-section .servicios-grid {
}

.servicios-section .servicio-card {
}

.servicios-section .servicio-titulo {
}

que tener las reglas mezcladas sin organización entre muchas otras secciones.

Comentarios en CSS

En personalizaciones complejas puedes utilizar comentarios:

/* Servicios */

/* Tarjetas de categorías */

/* Ajustes responsive */

Ayudan a localizar cada área.

20. Mantén las media queries organizadas

Por ejemplo:

/* Desktop/base */

.servicios-section .servicio-card {
    padding: 24px;
}

/* Mobile */

@media (max-width: 768px) {
    .servicios-section .servicio-card {
        padding: 16px;
    }
}

Esto resulta más sencillo de interpretar.

Evita una media query para cada pequeño ajuste

Antes de agregar:

@media ...
@media ...
@media ...
@media ...

revisa si puedes resolver el comportamiento mediante:

• Grid Row;

• columnas;

• Wrap;

• Width;

• Max Width;

• Margin;

• Padding.

21. Utiliza las herramientas responsive antes de escribir CSS adicional

Para distribución utiliza primero:

Grid Row

y las configuraciones de columnas.

Para ocultar:

Avanzado → Hide based on device screen width

Para tamaños:

Estilo → Size

Para espacios:

Margin / Padding

Solo crea media queries cuando realmente necesites un comportamiento no disponible visualmente.

22. No ocultes contenido importante para solucionar problemas responsive

Si tres Cards no entran en móvil:

[ 1 ] [ 2 ] [ 3 ]

no significa que debas ocultar dos.

Adapta:

[ 1 ]

[ 2 ]

[ 3 ]

La función de Hide debe utilizarse cuando verdaderamente quieres que determinado contenido no aparezca en un tamaño.

23. Evita Width y Height rígidos innecesarios

Por ejemplo:

width: 1200px;

puede provocar desbordamiento en móvil.

Utiliza dimensiones fijas cuando la composición realmente las necesite

Pero revisa siempre:

• desktop;

• tablet;

• celular.

Height fijo y texto

Una Card con:

height: 280px;

puede funcionar mientras tenga poco texto.

Si posteriormente alguien agrega una descripción más extensa:

Texto más largo...

puede aparecer:

• desbordamiento;

• recorte;

• superposición.

En muchos casos conviene utilizar

• altura automática;

• Min Height;

• estructura flexible.

24. Utiliza imágenes pensando en su función

No todas las imágenes deberían utilizar el mismo comportamiento.

Productos y logotipos

Puede ser importante mostrar todo el contenido:

object-fit: contain;

Fotografías decorativas

Puede ser más importante llenar el contenedor:

object-fit: cover;

No apliques globalmente

img {
    object-fit: cover;
}

si algunas imágenes necesitan mostrarse completas.

Utiliza una Class específica.

25. Mantén los textos fuera del HTML cuando puedan editarse visualmente

Si el usuario necesitará modificar con frecuencia:

• títulos;

• párrafos;

• botones;

• enlaces;

es conveniente mantener esos componentes fácilmente accesibles desde el editor cuando sea posible.

No conviertas innecesariamente una sección sencilla en un gran bloque de HTML difícil de editar.

Piensa también en el mantenimiento futuro

Una sección no debería ser fácil de construir solamente hoy.

También debería ser razonablemente sencilla de:

• cambiar dentro de seis meses;

• duplicar;

• traducir;

• actualizar;

• adaptar a una campaña diferente.

26. No conviertas todo en código porque una IA puede generarlo

ChatGPT, Claude o Gemini pueden generar una sección completa en HTML/CSS.

Eso no significa que siempre sea la mejor alternativa.

Una sección creada con componentes visuales puede ser:

• más fácil de editar;

• más fácil de reorganizar;

• más comprensible para otro usuario.

Utiliza bloques completamente personalizados cuando realmente aporten una ventaja.

Ejemplo

Para crear:

TÍTULO

TEXTO

BOTÓN

no necesitas necesariamente pedir a una IA un bloque de 200 líneas.

Puedes construirlo visualmente en pocos minutos.

En cambio

Para una composición avanzada con:

• tarjetas superpuestas;

• animaciones particulares;

• efectos complejos;

• responsive específico;

una IA puede ser una excelente ayuda.

27. Si utilizas IA, delimita claramente el alcance

Indica:

• Class principal;

• elementos internos;

• objetivo;

• comportamiento responsive;

• qué puede modificar;

• qué no debe modificar.

Ejemplo de buen pedido

La sección principal utiliza .servicios-section.

Las tarjetas utilizan .servicio-card.

Quiero que en desktop aparezcan tres por fila y en celular una por fila.

Las imágenes deben mostrarse completas sin deformarse.

Agrega un Hover suave que eleve 4 px cada tarjeta.

No modifiques otras secciones, Header, Footer ni estilos globales.

Utiliza CSS solamente. No agregues JavaScript.

28. Evita enviar todo el Code editor cuando no es necesario

El Code editor puede contener:

• HTML general;

• <head>;

• dependencias;

• scripts;

• integraciones;

• otras secciones.

Si necesitas ayuda sobre:

.servicios-section

envía principalmente:

• HTML relacionado;

• CSS relacionado;

• JavaScript relacionado solo si interviene.

29. Conserva una referencia del código original antes de una modificación grande

Si vas a reemplazar una cantidad importante de HTML o CSS, es recomendable conservar temporalmente el fragmento original.

Por ejemplo:

Original

.servicio-card {
    ...
}

Después prueba la nueva versión.

Si algo falla, disponer del fragmento anterior facilita restaurarlo.

No necesitas copiar toda la página

Guarda únicamente el fragmento relacionado cuando sea suficiente.

30. Realiza cambios progresivos

En lugar de cambiar simultáneamente:

• HTML;

• Grid;

• CSS;

• Hover;

• JavaScript;

• responsive;

puedes avanzar por etapas.

Ejemplo

Paso 1

Corrige estructura.

Paso 2

Comprueba desktop.

Paso 3

Configura responsive.

Paso 4

Agrega estilos.

Paso 5

Agrega Hover.

Paso 6

Agrega animaciones.

Paso 7

Comprueba todo.

Así puedes identificar rápidamente dónde aparece un problema.

31. Prueba después de cada cambio importante

No esperes a terminar toda la sección.

Después de modificar:

• estructura;

• Grid;

• HTML;

• CSS importante;

• JavaScript;

comprueba el resultado.

Esto evita acumular varios errores.

32. Utiliza Deshacer rápidamente

Si:

• eliminaste;

• moviste;

• cambiaste un estilo compartido;

• modificaste algo incorrectamente;

utiliza Deshacer cuanto antes.

Evita realizar numerosas modificaciones antes de corregir el error inicial.

33. Comprueba Linked styles antes de cambiar estilos importantes

Si Waclis muestra:

Linked styles

pregúntate:

¿Quiero modificar todos estos elementos?

Si la respuesta es sí:

puedes aprovechar el estilo compartido.

Si la respuesta es no:

necesitas una identificación más específica.

34. Evita agregar excepciones sobre excepciones

Supongamos que tienes:

.servicio-card {
}

Después:

.servicio-card.especial {
}

Luego:

.servicio-card.especial.otra {
}

Y posteriormente:

#servicio1 {
}

Si necesitas demasiadas excepciones para conseguir una estructura básica, quizá convenga revisar el diseño o la organización de Classes.

Una estructura clara suele necesitar menos correcciones

Antes de seguir agregando reglas pregúntate:

¿El problema está realmente en CSS o la estructura podría simplificarse?

35. No dupliques versiones desktop y móvil sin necesidad

Crear:

Sección Desktop

Sección Mobile

es válido cuando los diseños necesitan ser realmente diferentes.

Pero implica mantener dos versiones.

Si puedes resolverlo mediante:

• Grid;

• responsive;

• reorganización;

• tamaños;

es preferible mantener una única estructura.

36. Si duplicas versiones, documenta su función mediante Classes claras

Por ejemplo:

promo-desktop

promo-mobile

y configura correctamente su visibilidad.

Esto evita confundir posteriormente ambas versiones.

37. Prueba Hover sin depender de él

Los dispositivos táctiles no utilizan Hover de la misma manera que un mouse.

Utiliza Hover para:

• reforzar;

• destacar;

• responder visualmente.

No para esconder información esencial.

38. Utiliza animaciones de forma consistente

En una grilla de tres Cards:

Card 1
Card 2
Card 3

es más coherente utilizar:

• misma animación;

• Delay progresivo;

que tres efectos completamente diferentes sin una razón.

39. Evita animaciones sobre cada pequeño elemento

En lugar de:

Icon → animación
Heading → animación
Paragraph → animación
Button → animación

puede ser mejor animar:

Card completa

La composición suele sentirse más ordenada.

40. Revisa los elementos interactivos fuera del editor

Después de guardar comprueba:

• enlaces;

• botones;

• Tabs;

• Accordions;

• Sliders;

• Carousels;

• formularios;

• mapas;

• videos;

• iframes;

• scripts personalizados.

El aspecto visual por sí solo no confirma que la interacción funcione.

41. Comprueba el frontend con Ver página

Después de una personalización avanzada utiliza:

Ver página

No consideres terminada una sección únicamente porque se ve bien dentro del editor.

Comprueba

• textos;

• imágenes;

• links;

• responsive;

• Hover;

• animaciones;

• formularios;

• contenidos externos.

42. Prueba desktop, tablet y celular

Una revisión mínima debería contemplar:

COMPUTADORA
↓
TABLET
↓
CELULAR

Y, cuando sea posible, también un dispositivo real.

43. Busca scroll horizontal inesperado

En móvil, si puedes desplazarte lateralmente cuando no debería ocurrir, revisa:

• Width;

• Min Width;

• Margin;

• Position;

• imágenes;

• iframes;

• Grid;

• CSS personalizado.

44. Comprueba el contenido después de editar texto

Una Card puede estar perfectamente diseñada con:

Servicio
Texto breve

y romperse posteriormente cuando el contenido se convierte en:

Servicio de implementación y acompañamiento personalizado para empresas
Texto mucho más largo...

Los bloques deberían tolerar razonablemente variaciones de contenido.

Evita diseñar únicamente para el texto de ejemplo

Prueba con:

• títulos cortos;

• títulos largos;

• descripciones diferentes.

Especialmente en Cards repetidas.

45. Mantén coherencia visual

Un bloque personalizado debería integrarse con el resto de la Página web.

Revisa:

• tipografías;

• tamaños;

• colores;

• Border radius;

• botones;

• espacios;

• Hover;

• animaciones.

Un bloque técnicamente avanzado no necesita parecer completamente diferente al resto del sitio.

46. No utilices demasiadas tipografías

Mantener una cantidad limitada de familias tipográficas ayuda a conservar identidad visual.

Utiliza:

Typography

o las referencias de Variables cuando corresponda.

47. Mantén una escala de espacios coherente

Evita una sección con:

Padding 7px

Margin 53px

Padding 113px

Gap 19px

sin una razón concreta.

Trabajar con valores coherentes facilita el diseño.

Por ejemplo:

8
16
24
32
48
64

como referencia conceptual, adaptándolos al diseño.

No es obligatorio utilizar exactamente estos valores; la idea es mantener consistencia.

48. Mantén Border radius coherentes

Si la identidad visual utiliza Cards suavemente redondeadas, evita mezclar sin intención:

4px
17px
35px
50px

en cada tarjeta.

Las excepciones pueden existir, pero deberían responder a una decisión visual.

49. Utiliza variables CSS propias cuando ayuden

En un bloque complejo puedes definir:

.servicios-section {
    --card-radius: 16px;
    --card-gap: 24px;
}

Después:

.servicios-section .servicio-card {
    border-radius: var(--card-radius);
}

Esto ayuda cuando un valor se reutiliza varias veces.

50. No agregues variables para valores que solo se utilizan una vez

No necesitas convertir cada propiedad en una variable.

Utilízalas cuando realmente simplifiquen el mantenimiento.

51. Mantén las dependencias externas bajo control

En bloques avanzados pueden existir:

• scripts externos;

• estilos externos;

• embeds;

• bibliotecas;

• integraciones.

No elimines una dependencia simplemente porque no reconoces su nombre.

Primero identifica si está siendo utilizada.

52. Evita incorporar varias dependencias para resolver algo sencillo

Si un efecto puede conseguirse con:

transition

no necesitas necesariamente cargar otra biblioteca completa.

Cuantas más dependencias incorpores, mayor será la complejidad del bloque.

53. Cuidado con duplicar la misma dependencia

Si una biblioteca ya está disponible, agregarla nuevamente puede generar:

• carga innecesaria;

• conflictos;

• versiones diferentes;

• comportamientos inesperados.

Antes de agregar recursos externos desde un bloque avanzado, verifica si realmente son necesarios.

54. No modifiques recursos generales desde el Code editor sin necesidad

El Code editor puede mostrar mucho más código que el bloque que estás diseñando.

Puedes encontrar:

• <head>;

• scripts;

• recursos;

• integraciones;

• estilos generales.

No modifiques esas áreas si tu objetivo está limitado a una sección específica.

55. Utiliza Editar código HTML para cambios localizados

Cuando necesitas intervenir solamente sobre el elemento seleccionado:

Editar código HTML <>

puede ser más apropiado que recorrer todo el Code editor.

Primero selecciona el elemento mediante Navigator.

56. Utiliza CSS para apariencia y HTML para estructura

Esta separación ayuda a mantener el bloque comprensible.

Por ejemplo:

No es necesario colocar estilos repetidos directamente en cada etiqueta si puedes administrarlos mediante una Class.

En general:

HTML
→ estructura

CSS
→ apariencia

JavaScript
→ comportamiento

57. Evita estilos inline innecesarios en bloques complejos

Por ejemplo:

<div style="padding:24px;border-radius:16px;background:white">

puede funcionar.

Pero si tienes diez Cards iguales, una Class resulta más mantenible:

<div class="servicio-card">

y:

.servicio-card {
    padding: 24px;
    border-radius: 16px;
    background: white;
}

58. Mantén la semántica del contenido

Cuando trabajes con títulos utiliza niveles coherentes.

Por ejemplo:

H1 → título principal

H2 → sección

H3 → tarjeta o subsección

No utilices un Heading solamente porque visualmente tiene el tamaño que quieres.

El tamaño puede modificarse desde Typography.

59. Agrega Alt a imágenes relevantes

Cuando una imagen aporta información utiliza un texto alternativo descriptivo.

Ejemplo:

Equipo de atención al cliente reunido en una oficina

Evita:

foto3

60. Utiliza botones con textos claros

Es preferible:

Solicitar presupuesto

que:

Haz clic aquí

cuando puedes describir la acción directamente.

61. Revisa los enlaces después de clonar

Clonas una Card:

Servicio A
→ /servicio-a

La nueva Card puede mantener:

/servicio-a

hasta que lo cambies.

Comprueba siempre URLs en elementos clonados.

62. Revisa textos de botones clonados

Lo mismo ocurre con:

• labels;

• imágenes;

• Alt;

• títulos;

• IDs;

• links.

Una Card visualmente nueva puede mantener propiedades de la original.

63. Prueba el estado vacío o sin contenido cuando corresponda

Si un componente depende de contenido variable o reemplazable, considera qué sucederá cuando:

• una imagen falte;

• un texto sea muy corto;

• un título tenga dos líneas;

• un botón no sea necesario.

La estructura debería seguir siendo razonable.

64. Evita solucionar un problema agregando muchos parches

Si observas CSS como:

regla
↓
corrección
↓
corrección de la corrección
↓
!important
↓
otra media query
↓
otra excepción

puede ser momento de revisar la estructura original.

A veces reordenar correctamente:

Section
→ Row
→ Columns

es mejor que continuar agregando parches.

65. Si algo falla, diagnostica antes de modificar

Utiliza este procedimiento:

PROBLEMA
↓
DESHACER SI ES RECIENTE
↓
NAVIGATOR
↓
JERARQUÍA
↓
CLASS / ID
↓
LINKED STYLES
↓
RESPONSIVE
↓
CSS
↓
JAVASCRIPT SI EXISTE

No empieces necesariamente por CSS.

Pero tampoco existe una regla absoluta de que CSS deba ser siempre lo último.

Si sabes que el problema es una regla CSS concreta, puedes intervenir directamente sobre ella.

Lo importante es diagnosticar correctamente la causa.

66. Diferencia entre problema estructural y problema visual

Problema estructural

Por ejemplo:

Image quedó fuera de Grid Column

Solución:

corregir la jerarquía.

Problema visual

Por ejemplo:

Card necesita Border radius

Solución:

Estilo o CSS.

Problema responsive

Por ejemplo:

3 columnas no se apilan en móvil

Solución:

Grid Row / responsive o CSS específico.

Problema de comportamiento

Por ejemplo:

Carrusel no avanza

Puede requerir revisar:

• configuración;

• HTML;

• scripts;

• dependencias.

Identificar la categoría del problema ayuda a elegir la herramienta adecuada.

67. Si una IA genera el bloque completo, revísalo antes de guardar

Comprueba especialmente:

• nombres de Classes;

• IDs duplicados;

• selectores globales;

• !important;

• Width fijos;

• Height fijos;

• media queries;

• JavaScript;

• dependencias externas;

• enlaces;

• responsive.

68. Pide a la IA que respete el código existente

Por ejemplo:

No elimines el JavaScript existente.

No cambies las Classes actuales.

No modifiques otras secciones.

Mantén todas las funcionalidades.

Devuelve solamente las líneas que debo agregar o reemplazar.

Esto reduce el riesgo de una reescritura innecesaria.

69. No asumas que una reescritura completa es mejor

Si una sección funciona correctamente salvo por:

las imágenes se recortan

puede bastar con modificar:

object-fit

No es necesario reconstruir:

• HTML;

• CSS;

• scripts;

• responsive.

70. Mantén bloques fáciles de transferir y comprender

Una buena personalización debería poder explicarse con algo como:

Section:
.servicios-section

Cards:
.servicio-card

Título:
.servicio-titulo

Responsive:
Grid + una media query

Interacción:
Hover CSS

Sin JavaScript adicional

Si para comprender una sección necesitas reconstruir mentalmente decenas de reglas sin relación aparente, probablemente convenga simplificarla.

71. Guarda periódicamente

Cuando avances correctamente en una composición utiliza:

Guardar Cambios

periódicamente.

Waclis mostrará la correspondiente notificación verde de confirmación.

No existe un segundo paso de publicación dentro del Editor de bloques.

72. Pero no guardes un cambio roto como referencia final

Antes de cerrar el trabajo comprueba que la última modificación funciona.

Si acabas de introducir un error, utiliza:

Deshacer

antes de continuar.

73. Realiza una revisión final completa

Antes de considerar terminado un bloque complejo comprueba:

Contenido

• títulos;

• textos;

• imágenes;

• Alt;

• botones;

• links.

Estructura

• Navigator;

• Sections;

• Rows;

• Columns;

• Cards.

Estilos

• colores;

• Typography;

• Margin;

• Padding;

• bordes;

• Hover.

Responsive

• desktop;

• tablet;

• celular.

Avanzado

• visibilidad;

• animaciones.

Código

• Classes;

• IDs;

• CSS;

• JavaScript;

• dependencias.

Funcionamiento

• links;

• botones;

• formularios;

• sliders;

• embeds.

74. Utiliza Ver página como prueba final

Después de guardar:

Ver página

y recorre el contenido como lo haría un visitante.

No te concentres solamente en la sección que acabas de modificar.

Observa también sus áreas cercanas para comprobar que el CSS no haya afectado otros contenidos.

Ejemplo de revisión

Modificaste:

Servicios

Después revisa:

Sección anterior
↓
Servicios
↓
Sección siguiente

Esto ayuda a detectar:

• Margin excesivo;

• fondos que se extienden;

• selectores que afectan otras áreas.

Checklist antes de guardar un bloque complejo

• La Section tiene una estructura clara.

• Grid Row y columnas están organizados correctamente.

• Navigator refleja la jerarquía esperada.

• Las Classes tienen nombres comprensibles.

• Los IDs son únicos.

• No eliminé Classes estructurales necesarias.

• El CSS tiene un scope suficientemente específico.

• No existen selectores globales innecesarios.

• Revisé Linked styles.

• Desktop funciona correctamente.

• Tablet funciona correctamente.

• Celular funciona correctamente.

• No existe scroll horizontal inesperado.

• Las imágenes no están deformadas.

• Los textos largos no rompen el diseño.

• Hover no contiene información imprescindible.

• Las animaciones no dificultan la lectura.

• Los enlaces funcionan.

• Los botones tienen la acción correcta.

• Revisé IDs y URLs de elementos clonados.

• Los scripts continúan funcionando.

• No eliminé dependencias desconocidas.

• El bloque funciona mediante Ver página.

Ejemplo de una sección bien organizada

Supongamos una sección de Servicios.

Estructura

Section
class="servicios-section"

└── Container
    ├── Heading
    │   class="servicios-titulo"
    │
    └── Grid Row
        ├── Card
        │   class="servicio-card"
        │
        ├── Card
        │   class="servicio-card"
        │
        └── Card
            class="servicio-card"

CSS

.servicios-section .servicio-card {
    padding: 24px;
    border-radius: 16px;
    transition: transform .3s ease;
}

.servicios-section .servicio-card:hover {
    transform: translateY(-4px);
}

@media (max-width: 768px) {
    .servicios-section .servicio-card {
        padding: 18px;
    }
}

¿Por qué es mantenible?

Porque resulta fácil comprender:

• qué Section controla el bloque;

• qué Class identifica las Cards;

• dónde está el Hover;

• dónde está responsive.

No depende de selectores globales ni de numerosos parches.

Ejemplo de una estructura que conviene revisar

.card {
    padding: 12px !important;
}

div.card {
    padding: 18px !important;
}

.row .card {
    padding: 22px !important;
}

@media (max-width: 900px) {
    .card {
        padding: 17px !important;
    }
}

@media (max-width: 850px) {
    .card {
        padding: 16px !important;
    }
}

Puede funcionar, pero resulta difícil saber:

• qué Card alcanza;

• cuál regla gana;

• por qué existen tantos valores;

• qué sucederá al modificarla.

Conviene revisar la estructura y simplificar.

El objetivo no es escribir menos código a cualquier costo

Un bloque puede necesitar bastante CSS y seguir estando bien construido.

Lo importante es que el código sea:

• intencional;

• organizado;

• localizado;

• comprensible;

• necesario.

Una sección compleja puede requerir una cantidad considerable de código si el diseño lo justifica.

Tampoco existe una regla de “no empezar por CSS”

Si estás corrigiendo un bloque existente y sabes que el problema es:

object-fit: cover;

puedes modificar directamente esa regla.

En cambio, si todavía estás diseñando una estructura desde cero, normalmente será más conveniente definir primero:

• Section;

• Row;

• Columns;

• componentes.

La herramienta adecuada depende de la tarea.

Prioriza diagnóstico sobre reglas absolutas

Antes de decidir qué hacer, identifica:

¿Es contenido?

→ Contenido.

¿Es apariencia?

→ Estilo / CSS.

¿Es estructura?

→ Navigator / Componentes / HTML.

¿Es responsive?

→ Grid / Avanzado / CSS.

¿Es comportamiento?

→ configuración del componente / JavaScript si corresponde.

Este criterio es más útil que imponer un único flujo para todas las situaciones.

Flujo recomendado para crear un bloque avanzado desde cero

1. OBJETIVO
↓
2. ESTRUCTURA
↓
3. SECTION / CONTAINER / GRID
↓
4. COMPONENTES
↓
5. CONTENIDO
↓
6. CLASSES
↓
7. ESTILO
↓
8. RESPONSIVE
↓
9. CSS AVANZADO SI ES NECESARIO
↓
10. JAVASCRIPT SI REALMENTE ES NECESARIO
↓
11. PRUEBAS
↓
12. GUARDAR
↓
13. VER PÁGINA

Flujo recomendado para modificar un bloque avanzado existente

1. IDENTIFICAR EL PROBLEMA
↓
2. NAVIGATOR
↓
3. ELEMENTO
↓
4. CLASS / ID
↓
5. LINKED STYLES
↓
6. IDENTIFICAR SI ES HTML / CSS / RESPONSIVE / JS
↓
7. REALIZAR CAMBIO PUNTUAL
↓
8. COMPROBAR
↓
9. GUARDAR
↓
10. VER PÁGINA

Errores frecuentes

Crear la estructura mediante Margin y Position en lugar de Grid

Puede fallar responsive.

Utilizar Classes como .card, .title o .image sin limitar el alcance

Puede modificar otros contenidos.

Eliminar Classes internas sin saber para qué sirven

Puede romper estructura o responsive.

Repetir IDs después de clonar

Cada ID debe permanecer único.

Utilizar CSS para corregir una jerarquía incorrecta

Revisa Navigator primero.

Utilizar JavaScript para un Hover sencillo

CSS puede ser suficiente.

Crear numerosas media queries antes de revisar Grid Row

Utiliza primero el sistema responsive del editor.

Depender de Hover para mostrar información importante

No funciona de igual forma en dispositivos táctiles.

Crear versiones desktop/mobile de todo

Mantén una única estructura siempre que pueda adaptarse.

Copiar todo el Code editor a una IA

Aísla el fragmento necesario.

Aceptar una reescritura completa para una corrección mínima

Realiza cambios localizados.

Acumular !important

Revisa especificidad y scope.

No comprobar links después de clonar

Las copias pueden mantener el destino original.

Diseñar para un único tamaño de texto

Prueba contenidos de diferentes longitudes.

No utilizar Ver página

La validación final debe realizarse también en el frontend.

En resumen

Un bloque avanzado no necesita ser difícil de mantener.

Las principales buenas prácticas son:

• definir primero el objetivo;

• organizar la jerarquía;

• utilizar correctamente Section, Container, Grid Row y columnas;

• utilizar Navigator;

• asignar Classes descriptivas;

• mantener IDs únicos;

• aprovechar estilos compartidos;

• delimitar CSS mediante scope;

• evitar selectores globales;

• conservar Classes estructurales;

• trabajar responsive desde el principio;

• utilizar HTML cuando necesites modificar estructura;

• utilizar CSS para personalización visual avanzada;

• utilizar JavaScript solamente cuando aporte un comportamiento necesario;

• realizar cambios progresivos;

• probar antes y después;

• utilizar Ver página como validación final.

La regla central puede resumirse así:

Un buen bloque personalizado no es solamente el que se ve bien, sino también el que puede entenderse, modificarse y mantenerse con seguridad.

No existe una única forma correcta de comenzar todas las modificaciones.

En lugar de aplicar reglas absolutas, identifica primero qué tipo de problema tienes y utiliza la herramienta correspondiente.

Esto permite crear bloques avanzados sin convertir la Página web en una colección de excepciones difíciles de administrar.