El Editor de bloques de Waclis incluye diferentes herramientas relacionadas con código.

Aunque pueden parecer similares, no cumplen la misma función.

Entre ellas encontrarás:

• el componente Code;

• el componente Preformatted;

• Editar código HTML <> del elemento seleccionado;

• Code editor;

• el editor de CSS disponible desde Variables/CSS.

Comprender esta diferencia es fundamental antes de realizar modificaciones avanzadas.

En este tutorial aprenderás:

• para qué sirve el componente Code;

• qué diferencia existe entre Code y Preformatted;

• qué hace Editar código HTML <>;

• qué alcance tiene Code editor;

• cuándo utilizar CSS en lugar de modificar HTML;

• por qué no conviene abrir el código para cambios que pueden realizarse visualmente;

• cómo trabajar con HTML de forma segura;

• cómo reconocer estructuras de Container, Grid, Cards y componentes;

• qué precauciones tomar con IDs y Classes;

• cómo trabajar con componentes interactivos;

• qué riesgos existen al modificar código global;

• cómo utilizar JavaScript solamente cuando realmente sea necesario;

• cómo pedir ayuda a ChatGPT, Claude o Gemini sin permitir que reescriban innecesariamente toda la página;

• cómo realizar una comprobación final antes de guardar.

Existen varias herramientas de código y no son equivalentes

Esta es la primera distinción que debes aprender.

CODE
→ componente que forma parte del contenido

PREFORMATTED
→ componente para mostrar texto conservando formato

EDITAR CÓDIGO HTML <>
→ HTML del elemento seleccionado

CODE EDITOR
→ código de una estructura mucho más amplia

VARIABLES / CSS
→ reglas CSS del diseño

No utilices una herramienta solamente porque dice “Code”

Antes de abrir cualquier editor pregunta:

¿Qué quiero modificar exactamente?

Si quieres cambiar un texto

utiliza:

Contenido

Si quieres cambiar color, tamaño o espacios

utiliza:

Estilo

Si quieres modificar solamente el HTML de una Card

puede corresponder:

Editar código HTML <>

Si necesitas una regla visual específica

puede corresponder:

Variables/CSS → Css

Si necesitas revisar una estructura extensa

recién entonces puede tener sentido utilizar:

Code editor

Primera regla

Utiliza siempre la herramienta de menor alcance que pueda resolver correctamente el cambio.

Ejemplo

Quieres cambiar:

Título actual

por:

Nuevo título

No necesitas Code editor

Selecciona Heading y modifica el contenido.

Quieres cambiar:

font-size

No necesitas editar HTML.

Utiliza:

Estilo → Typography

Quieres agregar:

border-radius

Utiliza Estilo cuando la opción exista.

Solo avanza hacia código cuando las herramientas visuales no resuelvan adecuadamente la necesidad.

1. ¿Qué es el componente Code?

Dentro de:

Componentes → Elementos

encontrarás:

Code

Este componente permite incorporar un fragmento de código como parte del contenido de la Página web.

Por ejemplo

puedes mostrar:

print "Hello world!"

Al seleccionar el componente Code

dentro de Contenido encontrarás un campo:

Text

donde puedes modificar el texto mostrado.

¿Para qué puede utilizarse?

Puede ser útil en:

• documentación técnica;

• tutoriales;

• ejemplos;

• manuales;

• páginas destinadas a desarrolladores.

Ejemplo

EJEMPLO DE CSS

[ CODE ]

.product-card {
    border-radius: 12px;
}

Otro ejemplo

EJEMPLO HTML

[ CODE ]

<a href="/contacto">Contactar</a>

Code muestra contenido

No debes considerar el componente Code como una herramienta destinada a ejecutar automáticamente el código que escribes.

Por ejemplo

si escribes:

<script>
alert("Hola");
</script>

dentro de un componente pensado para mostrar código,

no deberías utilizarlo esperando crear una funcionalidad JavaScript.

Conceptualmente

CODE COMPONENT
→ mostrar código al visitante

no:

CODE COMPONENT
→ programar la página

Esto es fundamental

Code vs Editar código HTML

El componente Code:

muestra código como contenido

Editar código HTML:

modifica la estructura HTML real del elemento

Son cosas completamente diferentes.

Ejemplo

Quieres enseñar:

<h2>Mi título</h2>

Utiliza:

Code

Quieres modificar realmente el <h2> de una Card:

utiliza:

Editar código HTML <>

cuando sea necesario.

No confundas “mostrar HTML” con “editar HTML”

2. ¿Qué es Preformatted?

Dentro de los componentes Base también encontrarás:

Preformatted

Este componente permite mostrar texto conservando una disposición preformateada.

Puede resultar útil para:

• texto con espacios;

• estructuras alineadas;

• ejemplos simples;

• información donde los saltos de línea sean importantes.

Ejemplo

Nombre:      Producto A
Código:      ABC-123
Estado:      Disponible

Preformatted vs Paragraph

Un Paragraph normalmente adapta el texto según el flujo habitual.

Preformatted

puede conservar mejor:

• saltos;

• espacios;

• organización original.

Preformatted vs Code

Esta diferencia también es importante.

Preformatted

puede contener:

Lunes       09:00
Martes      09:00
Miércoles   09:00

Code

es más apropiado conceptualmente para:

.card {
    padding: 20px;
}

No todo texto preformateado es código

Y no todo contenido que necesita saltos de línea necesita Code.

¿Cuándo utilizar Table en lugar de Preformatted?

Supongamos:

Producto      Precio      Stock
A             100         5
B             200         10

Eso es información tabular.

Puede ser más correcto utilizar:

Table

Preformatted no debería utilizarse para recrear tablas complejas mediante espacios.

Especialmente en celular

porque:

espacios fijos

pueden generar desbordamiento.

3. ¿Qué es Editar código HTML <>?

Cuando seleccionas un elemento dentro del lienzo aparece una barra contextual.

Entre sus herramientas se encuentra:

Editar código HTML <>

Esta herramienta permite trabajar con el HTML del elemento seleccionado.

Es una de las herramientas avanzadas más útiles del Editor

porque permite modificar una parte específica

sin abrir necesariamente el código general de toda la página.

Ejemplo

Seleccionas:

Card

Después:

<>
Editar código HTML

Se abre un editor donde puedes revisar la estructura HTML correspondiente al elemento seleccionado.

Conceptualmente

<div class="mi-card">
    <h3>Título</h3>
    <p>Descripción</p>
</div>

Puedes realizar modificaciones

y utilizar:

Save Changes

dentro de ese editor.

Después

cuando termines el trabajo general,

utiliza:

Guardar Cambios

en la parte superior del Editor de bloques.

No existe un segundo paso de “publicar”

El flujo es:

EDITAR HTML
↓
SAVE CHANGES EN EL MODAL
↓
REVISAR RESULTADO
↓
GUARDAR CAMBIOS

¿Cuándo conviene utilizar Editar código HTML?

Cuando necesitas modificar algo que no puede resolverse fácilmente mediante:

• Contenido;

• Estilo;

• Avanzado.

Por ejemplo

puedes necesitar:

• agregar una Class;

• reorganizar una pequeña estructura;

• revisar un atributo;

• identificar un wrapper;

• corregir HTML de un componente;

• entender una relación interna.

Pero no abras HTML para cualquier cambio

Ejemplo innecesario

Quieres cambiar:

Nuestro servicio

por:

Consultoría

Utiliza Contenido.

Otro ejemplo

Quieres:

margin-top: 20px

Utiliza Estilo.

HTML debería ser una herramienta de precisión

no la primera opción.

Alcance del HTML depende de lo seleccionado

Este es un punto fundamental.

Si seleccionas:

Heading

el HTML disponible será diferente que si seleccionas:

Card

Y diferente si seleccionas:

Section

Por eso

antes de utilizar <>:

comprueba qué elemento está seleccionado.

Navigator es fundamental

Ejemplo

Quieres modificar toda esta unidad:

Card
├── Image
├── Heading
├── Paragraph
└── Link

Pero tienes seleccionado:

Paragraph

Si abres HTML

verás una estructura mucho más limitada.

Utiliza:

• Navigator;

• Seleccionar padre;

hasta seleccionar:

Card

Después abre:

Editar código HTML

4. ¿Por qué Navigator es fundamental antes de editar código?

Navigator permite comprender la jerarquía.

Ejemplo

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

Sin Navigator

puedes creer que estás editando:

Card

cuando realmente seleccionaste:

Column

La diferencia es importante

Si modificas Column

puedes afectar:

• ancho;

• Grid;

• responsive.

Si modificas Card

puedes afectar:

• contenido;

• diseño de esa unidad.

Siempre confirma el nivel.

Seleccionar padre

La herramienta:

Seleccionar padre

permite subir en la jerarquía.

Por ejemplo

Heading
↓
Card
↓
Column
↓
Grid Row

Pero no sigas seleccionando padre sin observar qué nivel alcanzaste.

Podrías terminar editando:

BODY

o una estructura mucho más amplia de la esperada.

5. Antes de modificar HTML, guarda una copia

Esta es una de las mejores prácticas más importantes.

Antes de modificar un fragmento complejo

copia el HTML actual.

Por ejemplo

<div class="original-card">
    ...
</div>

Guárdalo temporalmente en:

• un editor de texto;

• una nota;

• otro lugar seguro.

De esta forma

si tu modificación falla,

puedes recuperar:

la versión anterior del fragmento

No dependas exclusivamente de recordar qué cambiaste.

Especialmente antes de:

• eliminar wrappers;

• modificar IDs;

• cambiar Classes;

• reorganizar componentes interactivos.

Waclis dispone de Deshacer para operaciones dentro del editor

pero conservar una copia del fragmento antes de una modificación avanzada sigue siendo una práctica recomendable.

No existe autosave que debas dar por supuesto

Guarda en momentos lógicos.

6. ¿Qué partes del HTML no deberías eliminar sin comprenderlas?

Especialmente:

• Classes;

• IDs;

• atributos;

• wrappers;

• controles;

• elementos relacionados con interacción.

Ejemplo

<div class="card">

Puede parecer que:

class="card"

solo sirve para el estilo.

Pero también puede participar en:

• estructura;

• CSS existente.

Si la eliminas

la Card puede cambiar completamente.

Otro ejemplo

id="panel-2"

dentro de Tabs o Accordeon.

Ese ID puede relacionar:

CONTROL
↔
PANEL

No lo elimines solamente porque:

“no aparece visualmente”.

HTML contiene información que el visitante no ve

pero que puede ser funcional.

7. Classes: qué son y por qué importan

Una Class puede aplicarse a varios elementos.

Ejemplo

<div class="product-card">

Varias Cards pueden compartir:

product-card

Eso permite aplicar el mismo CSS.

Por ejemplo:

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

Entonces todas las Cards con esa Class pueden recibir el mismo tratamiento.

Por eso

si modificas una Class compartida:

puedes afectar varios elementos.

Esto es exactamente lo que explica el aviso:

Linked styles

Un cambio puede afectar otros elementos que comparten selector.

No es necesariamente un error

Puede ser intencional.

Ejemplo

Quieres que todas:

.service-card

tengan el mismo Border radius.

Perfecto.

Pero si solamente una debe cambiar

no modifiques la Class compartida.

Puedes agregar una Class adicional.

Por ejemplo

<div class="service-card service-card-featured">

Después:

.service-card-featured {
    ...
}

8. IDs: deben ser únicos

A diferencia de una Class:

ID
→ debe ser único

Ejemplo

<section id="contacto">

No deberías tener:

<section id="contacto">

en dos lugares diferentes de la misma página.

Esto es especialmente importante al clonar.

Si clonas una Section

que contiene:

id="servicios"

comprueba el resultado.

No dejes el mismo ID en la copia.

IDs y enlaces internos

Supongamos:

<section id="preguntas">

Un Link puede utilizar:

#preguntas

Si cambias el ID a:

faq

pero mantienes el Link:

#preguntas

el enlace puede dejar de llevar al destino esperado.

Por eso

cuando cambias un ID:

busca qué otros elementos pueden estar utilizándolo.

No renombres IDs solamente para que el código “se vea más bonito”.

9. Linked styles antes de modificar código

El Editor puede mostrar un aviso indicando que el elemento comparte estilos con otros.

Por ejemplo

puede aparecer una estructura como:

#ntx-carousel-track-1 > .ntx-slide > .ntx-link > .ntx-img

Esto te indica

que el selector utilizado puede estar relacionado con otros elementos.

Antes de aplicar un cambio

pregunta:

¿Quiero modificar todos los elementos que comparten este estilo?

Si sí:

utiliza el selector compartido.

Si no:

puedes necesitar:

• una Class adicional;

• un ID único;

según el caso.

No agregues IDs únicos a todos los elementos por defecto

La reutilización de Classes es precisamente lo que permite diseños consistentes.

10. HTML y Bootstrap 4

La Página web de Waclis utiliza actualmente:

Bootstrap 4

Esto es importante cuando trabajas manualmente con:

• Container;

• Row;

• Columns;

• Buttons;

• Cards;

• navegación.

Por ejemplo

una estructura puede utilizar:

<div class="row">
    <div class="col-sm-4">
        ...
    </div>
</div>

No reemplaces automáticamente estas Classes por ejemplos de Bootstrap 5 encontrados en Internet.

Podrías introducir incompatibilidades.

Si pides código a una IA

indica siempre:

La Página web utiliza Bootstrap 4.

No le digas simplemente:

“moderniza este Bootstrap”.

Puede cambiar versiones sin que lo hayas pedido.

11. ¿Qué es Code editor?

En la parte inferior derecha del Editor de bloques existe:

Code editor

Esta herramienta permite trabajar con código de una estructura mucho más amplia que el elemento seleccionado.

Por eso representa un nivel de intervención mayor.

Conceptualmente

EDITAR HTML <>
→ elemento seleccionado

Mientras:

CODE EDITOR
→ estructura más amplia

Esta diferencia es fundamental

Si solamente quieres modificar una Card

no necesitas abrir Code editor.

Si quieres revisar o trabajar con una estructura global más amplia

puede ser útil.

Code editor no debería ser tu primera herramienta

Porque cuanto mayor es el alcance:

mayor es la posibilidad de modificar algo que no querías tocar.

Ejemplo

Quieres cambiar:

un Button

Abres Code editor

y terminas modificando:

• Row;

• Column;

• otra Card;

• otras Sections.

Era innecesario.

Utiliza el nivel mínimo necesario.

12. ¿Cuándo puede resultar útil Code editor?

Puede ser útil para usuarios avanzados cuando necesitas:

• estudiar una estructura extensa;

• buscar una relación entre varios elementos;

• realizar una revisión de código;

• corregir una construcción que involucra varias partes;

• trabajar con una personalización global cuidadosamente planificada.

Pero antes de modificar

debes comprender:

• qué parte estás viendo;

• qué elementos dependen de ella.

No elimines bloques grandes

porque:

“parecen repetidos”

Pueden corresponder a:

• desktop/mobile;

• contenido estructural;

• componentes interactivos;

• wrappers necesarios.

Investiga primero.

13. Editar HTML vs Code editor

Una regla práctica:

UN ELEMENTO
→ <>

UNA ESTRUCTURA AMPLIA
→ Code editor

Por ejemplo

Modificar el HTML de:

Card de servicio

→ <>

Revisar una estructura mucho más extensa:

→ Code editor

No subas de nivel sin necesidad.

14. ¿Dónde editar CSS?

Dentro del Editor de bloques puedes abrir:

Variables/CSS

mediante el icono correspondiente.

Allí encontrarás:

• Variables;

• Css.

El área Css permite trabajar con reglas CSS.

Ejemplo:

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

Esto es diferente de editar HTML.

HTML define estructura

<div class="mi-card">
    ...
</div>

CSS define presentación

.mi-card {
    background-color: ...;
}

Regla básica

HTML
→ estructura y contenido

CSS
→ apariencia

No modifiques HTML para resolver algo que es puramente visual

Ejemplo

Quieres cambiar:

Padding

No agregues wrappers innecesarios.

Utiliza:

• Estilo;

• CSS.

Quieres cambiar:

orden estructural de dos elementos

Eso sí puede requerir:

• mover;

• Grid;

• HTML.

15. Utiliza primero Estilo

Antes de escribir CSS manual

revisa las opciones disponibles.

En Estilo puedes trabajar con

• Display;

• Typography;

• Size;

• Margin;

• Padding;

• Border;

• Border radius;

• Background Image.

También estados:

• Hover;

• Active;

• nth-of-type(2n).

Si la opción ya existe

utilízala.

Ejemplo

Quieres:

margin-bottom: 24px

No necesitas escribir:

.elemento {
    margin-bottom: 24px;
}

si puedes configurarlo desde Estilo.

CSS manual puede ser necesario

cuando necesitas:

• un selector específico;

• media queries;

• una combinación no disponible visualmente;

• una personalización avanzada.

16. CSS localizado vs CSS global

Esta es una de las reglas más importantes de toda la personalización.

Evita:

h2 {
    font-size: 60px;
}

si solo quieres cambiar:

un Heading

Esa regla puede afectar todos los <h2>.

Mejor

agrega una Class específica.

Por ejemplo

hero-title-custom

CSS:

.hero-section .hero-title-custom {
    font-size: 60px;
}

Mucho más seguro.

Otro ejemplo peligroso

img {
    width: 100%;
}

Puede afectar:

• Logo;

• Gallery;

• producto;

• iconos convertidos en imágenes;

• otras zonas de la Página web.

Mejor:

.project-gallery .gallery-image {
    width: 100%;
}

Evita globalmente

svg {
    width: 50px;
}

Puede afectar:

• logos;

• controles;

• iconos.

Evita:

button {
    border-radius: 30px;
}

globalmente.

Puede cambiar:

• formularios;

• checkout;

• otros componentes.

CSS global puede afectar elementos fuera del bloque que estás editando

Por eso

utiliza scope siempre que sea posible.

17. ¿Qué significa scope?

Significa limitar una regla a una zona concreta.

Por ejemplo

Section:

services-section

Card:

service-card

CSS:

.services-section .service-card {
    border-radius: 16px;
}

Esto reduce la posibilidad de modificar:

otras Cards

El scope es una de las mejores formas de mantener CSS seguro.

18. Media queries

CSS puede utilizarse para realizar ajustes responsive.

Por ejemplo

.hero-title {
    font-size: 48px;
}

@media (max-width: 576px) {
    .hero-title {
        font-size: 32px;
    }
}

Pero no escribas media queries

si las herramientas responsive existentes resuelven adecuadamente el diseño.

Recuerda además

los iconos superiores de:

• teléfono;

• tablet;

• computadora;

sirven para:

previsualizar

Mientras:

Avanzado → Hide based on device screen width

controla:

visibilidad real

CSS y responsive son otra capa diferente.

No confundas las tres cosas.

19. Breakpoints

Dentro de Variables puedes visualizar valores relacionados con breakpoints del sistema.

Entre los valores confirmados se encuentran:

xs = 0
sm = 576 px
md = 768 px
lg = 992 px

Utilízalos como referencia cuando necesites mantener coherencia con la estructura responsive existente.

No inventes breakpoints diferentes en cada sección

sin una razón.

Por ejemplo

631 px
747 px
913 px

pueden volver difícil mantener el CSS.

Utiliza un sistema consistente.

20. !important

Evita utilizar:

!important

como primera solución.

Por ejemplo:

.my-title {
    color: red !important;
}

Puede funcionar,

pero también:

• dificulta modificaciones posteriores;

• crea conflictos;

• obliga a utilizar más !important.

Antes de usarlo

pregunta:

¿El problema es que mi selector no tiene suficiente especificidad?

Puede ser mejor:

.my-section .my-title {
    ...
}

No construyas una cadena de !important.

21. ¿Qué ocurre si un CSS afecta más elementos de los esperados?

Primero revisa:

• selector;

• Class;

• ID;

• scope;

• Linked styles.

Ejemplo

Escribiste:

.card {
    border: none;
}

Ahora todas las Cards cambiaron.

El problema no está en cada Card.

El problema es:

selector demasiado global

Corrige a:

.my-services-section .card {
    ...
}

si ese es el alcance deseado.

22. ¿Qué ocurre si una regla no se aplica?

No agregues inmediatamente:

!important

Revisa primero:

1. ¿la Class existe?

2. ¿el selector es correcto?

3. ¿estás seleccionando el elemento adecuado?

4. ¿otra regla tiene mayor prioridad?

5. ¿hay un estilo inline?

6. ¿el selector corresponde a la jerarquía real?

Utiliza HTML y Navigator para comprobar.

23. Editar código de componentes interactivos

Especial cuidado con:

• Tabs;

• Accordeon;

• Carousel;

• Slider;

• Flip box;

• Image Compare;

• componentes personalizados.

Estos componentes pueden utilizar:

• IDs;

• Classes;

• atributos;

para relacionar diferentes partes.

Ejemplo conceptual

Tab Control
→ Panel

Si eliminas:

id

o una referencia relacionada:

puede dejar de funcionar.

Por eso

antes de editar HTML de un componente interactivo:

1. COPIAR HTML ORIGINAL
2. IDENTIFICAR ESTRUCTURA
3. IDENTIFICAR IDS
4. IDENTIFICAR CLASSES
5. MODIFICAR SOLO LO NECESARIO
6. PROBAR TODA LA INTERACCIÓN

No reescribas desde cero un componente que ya funciona

solamente para cambiar su apariencia.

Usa CSS.

24. Editar HTML de Tabs

Si necesitas agregar una pestaña manualmente:

primero identifica:

Control A
↔
Panel A

La nueva debe tener:

Control B
↔
Panel B

No clones IDs.

Tampoco cambies solamente:

Panel B

sin actualizar su referencia.

El código puede seguir siendo válido sintácticamente

pero la interacción puede quedar rota.

“HTML válido” no siempre significa:

“componente funcional”.

25. Editar HTML de Accordeon

Mismo principio.

Cada Item puede contener:

Header / Control
+
Panel

No elimines solamente uno.

Si trabajas manualmente:

mantén la relación.

Después prueba:

• todos los Items;

• no solamente el modificado.

26. Editar HTML de Carousel o Slider

Antes de clonar manualmente:

identifica:

Track
Slide
Controls

No clones:

Image

si necesitas un nuevo:

Slide

No elimines controles pensando que son decoración.

HTML puede contener elementos funcionales.

27. Editar HTML de Forms

Especial cuidado.

Un Form puede incluir:

• Input;

• Name;

• Type;

• valores;

• atributos.

No cambies:

name

o:

type

sin comprender cómo se procesa el formulario.

Un cambio visual no requiere modificar la lógica del Form.

Si el formulario ya funciona:

conserva sus atributos funcionales.

28. HTML Button vs Link

Recordemos una diferencia importante.

HTML Button

puede representar:

<button>

Link:

<a href="...">

Si quieres:

navegar a otra página

un Link suele ser conceptualmente apropiado.

No conviertas:

<button>

en navegación improvisada mediante JavaScript

si un <a> puede resolverlo.

Utiliza HTML semánticamente apropiado.

29. No agregues wrappers innecesarios

Supongamos:

<div>
    <div>
        <div>
            <div>
                <h2>Título</h2>
            </div>
        </div>
    </div>
</div>

A veces una estructura compleja es necesaria.

Pero no agregues nuevos:

<div>

para cada cambio visual.

Antes pregunta:

¿Puedo resolverlo con la estructura actual y CSS?

Menos estructura innecesaria facilita mantenimiento.

Sin embargo

tampoco elimines wrappers existentes solo para “limpiar”.

Pueden ser funcionales.

30. Código HTML y semántica

Utiliza elementos acordes al contenido.

Heading

<h2>

para un título estructural.

Paragraph

<p>

para texto.

Link

<a>

para navegación.

List

<ul>
<li>

para una lista.

No conviertas todo en:

<div>

solo porque visualmente puedes hacerlo funcionar.

La estructura semántica ayuda a mantener el contenido más comprensible.

31. Heading: HTML vs apariencia

Recuerda:

H1 / H2 / H3
→ estructura

Mientras:

Font size
→ apariencia

No cambies:

<h2>

por:

<h5>

solo porque quieres un texto más pequeño.

Mantén Heading correcto

y ajusta Typography.

32. Imágenes desde HTML

Una Image puede representarse conceptualmente mediante:

<img src="..." alt="...">

Si editas HTML:

no elimines:

alt

sin evaluar accesibilidad.

Tampoco cambies:

src

manualmente

si puedes utilizar:

Set Image

La herramienta visual puede ser más segura.

No escribas rutas manuales innecesariamente.

33. Links desde HTML

Conceptualmente:

<a href="/contacto">
    Contactar
</a>

Si solo necesitas cambiar destino:

utiliza Contenido → Url

cuando esté disponible.

No abras HTML.

Si necesitas revisar:

• rel;

• target;

• download;

también existen opciones dentro del componente Link.

Utiliza la interfaz primero.

34. ¿Cuándo usar JavaScript?

JavaScript debería reservarse para una funcionalidad que realmente lo necesite.

No lo utilices para:

• colores;

• Margin;

• Padding;

• Width;

• Typography;

• Border radius.

Eso corresponde a CSS.

Tampoco para:

abrir un Link normal

HTML puede resolverlo.

JavaScript puede ser necesario

para una interacción personalizada que:

• no existe en los componentes;

• requiere lógica.

Pero antes:

pregunta si Waclis ya posee un componente que la resuelve.

Ejemplo

Necesitas:

Accordion

No programes uno desde cero.

Utiliza:

Accordeon

Necesitas:

Slider

Utiliza Slider.

Necesitas:

Tabs

Utiliza Tabs.

No reconstruyas funciones disponibles.

35. No agregues librerías externas sin necesidad

Por ejemplo

un tutorial de Internet puede decir:

Agrega esta biblioteca...

Pero Waclis puede tener ya:

• Bootstrap;

• componentes;

• scripts propios.

Agregar otra biblioteca puede generar:

• conflictos;

• peso adicional;

• duplicación.

Antes pregunta:

¿Puedo resolverlo utilizando las herramientas existentes?

En muchos casos:

sí.

36. Código obtenido de Internet

No pegues código de:

• foros;

• tutoriales;

• repositorios;

sin entenderlo.

Revisa:

• versión;

• dependencias;

• compatibilidad;

• alcance.

Un ejemplo construido para:

Bootstrap 5

puede no ser adecuado para:

Bootstrap 4

Otro puede requerir:

jQuery plugin X

que no necesitas.

No copies ciegamente.

37. Código generado por IA

ChatGPT, Claude o Gemini pueden ayudarte enormemente,

pero debes proporcionar contexto.

Mal prompt

Hazme esto más moderno.

Puede producir:

• HTML completamente nuevo;

• nuevas librerías;

• código incompatible;

• estilos globales.

Mejor

Este es un bloque de Waclis.

Waclis utiliza Bootstrap 4.

Necesito modificar solamente el Border radius de las Cards.

No cambies HTML.
No agregues JavaScript.
No agregues librerías.
No modifiques otras secciones.

Cuanto más preciso sea el prompt

menor riesgo de cambios innecesarios.

38. Nunca envíes toda la página si solo necesitas modificar un elemento

Supongamos que necesitas corregir:

una Card

No es necesario pegar:

todo el HTML de la página

Utiliza:

Editar código HTML <>

y copia únicamente esa unidad.

Después pide:

Modifica únicamente este componente.

Esto reduce:

• errores;

• ruido;

• cambios colaterales.

39. Prompt recomendado para revisar HTML

Este es el HTML de un único componente de Waclis:

[pegar]

Waclis utiliza Bootstrap 4.

Primero identifica:
- contenedor raíz;
- elementos hijos;
- Classes;
- IDs;
- Links;
- estructura responsive.

No modifiques nada todavía.

Primero análisis

Después modificación.

No pidas directamente:

“Arreglalo”.

40. Prompt para una modificación visual

Este componente funciona correctamente:

[HTML]

Necesito solamente:
- Border radius de 16 px;
- sombra suave;
- Padding de 24 px.

No cambies:
- estructura HTML;
- IDs;
- Links;
- Bootstrap Classes.

No agregues JavaScript.

Devuélveme solamente CSS.

Esto es mucho más seguro.

41. Prompt para responsive

Este bloque de Waclis se ve correctamente en desktop pero mal en celular.

HTML:
[pegar componente]

CSS relacionado:
[pegar]

Waclis utiliza Bootstrap 4.

Analiza:
- width fija;
- min-width;
- grid;
- padding;
- margin;
- imágenes;
- overflow.

No utilices overflow-x:hidden como solución.
No reescribas todo el componente.

42. Prompt para detectar CSS global

Revisa este CSS:

[pegar]

Identifica selectores demasiado globales como:

body
h1
h2
p
a
img
svg
button
iframe
.row
.card

Señala qué otros elementos podrían verse afectados.

No modifiques el código todavía.

43. Prompt para Linked styles

Este elemento de Waclis comparte estilos con otros elementos.

Selector:
[pegar]

HTML:
[pegar]

Necesito modificar solamente esta instancia.

Indica si conviene:
- agregar una Class adicional;
- utilizar un ID único.

No modifiques las Classes estructurales existentes.

44. Prompt para IDs duplicados

Cloné este componente:

[HTML original]

[HTML copia]

Busca:
- IDs duplicados;
- references relacionadas;
- Links repetidos.

No inventes nuevos valores funcionales.
Indica qué debe revisarse.

45. Prompt para Tabs o Accordeon

Este componente interactivo de Waclis funciona actualmente:

[HTML]

Waclis utiliza Bootstrap 4.

Identifica:
- controles;
- paneles;
- IDs;
- referencias entre ambos;
- Classes de estado.

No modifiques nada.
No agregues JavaScript.

Después de comprenderlo

puedes pedir una modificación puntual.

46. Prompt para modificar una estructura

Quiero agregar un cuarto Item.

HTML actual:
[pegar]

Ya identificamos el patrón.

Necesito:
- clonar solamente la unidad repetible;
- conservar Classes estructurales;
- crear IDs nuevos donde corresponda;
- mantener referencias correctas.

No reescribas todo el componente.

47. Prompt para CSS mobile

Tengo esta Section:

Class raíz:
.mi-seccion

Necesito:

Desktop:
3 columnas.

Tablet:
2 columnas.

Mobile:
1 columna.

Waclis utiliza Bootstrap 4.

Primero evalúa si puede resolverse con las Classes existentes del Grid.

Solo genera CSS si realmente es necesario.
No agregues JavaScript.

Este prompt evita CSS innecesario.

48. Prompt para detectar JavaScript innecesario

Revisa este código:

[pegar]

Identifica qué partes utilizan JavaScript únicamente para:
- estilos;
- mostrar/ocultar estáticamente;
- navegación simple.

Indica si podrían resolverse con HTML/CSS o componentes existentes de Waclis.

No elimines nada todavía.

49. Prompt para revisar Bootstrap 4

Este HTML se utilizará en Waclis, que actualmente utiliza Bootstrap 4:

[HTML]

Busca:
- Classes exclusivas de versiones posteriores;
- estructuras que puedan ser incompatibles.

No migres el código.
Solo señala riesgos.

50. Prompt para crear una Section desde cero

Si realmente necesitas construir una estructura personalizada:

Necesito crear una Section para Waclis.

Waclis utiliza Bootstrap 4.

Contenido:
[describir]

Necesito:
- Container;
- Row;
- columnas responsive;
- Classes propias con prefijo `custom-`;
- HTML semántico;
- CSS localizado.

No incluyas:
- Header;
- Footer;
- Bootstrap externo;
- jQuery externo;
- nuevas librerías.

No utilices IDs salvo que sean necesarios.

Esto evita duplicar recursos ya existentes.

51. No incluyas Bootstrap desde CDN dentro de una Section

No agregues:

<link rel="stylesheet" href="...bootstrap...">

dentro de cada bloque.

Waclis ya utiliza Bootstrap 4.

Cargar otra versión puede generar conflictos.

Tampoco agregues:

<script src="...bootstrap..."></script>

sin una necesidad específica y validada.

No dupliques las dependencias de la Página web.

52. No agregues jQuery nuevamente sin necesidad

Si encuentras un ejemplo que comienza:

<script src="jquery..."></script>

no significa que debas copiarlo.

Una segunda carga de jQuery puede generar conflictos.

Utiliza primero el entorno existente.

53. No agregues un <html>, <head> o <body> dentro de una Section

Si estás editando un bloque:

no construyas:

<!DOCTYPE html>
<html>
<head>
...
</head>
<body>
...
</body>
</html>

dentro de la Section.

Estás trabajando dentro de una Página web ya existente.

Normalmente necesitas:

<section>
...
</section>

o la estructura correspondiente.

No recrees el documento entero dentro de un bloque.

Esta es una recomendación especialmente importante al utilizar IA

Muchos generadores devuelven una página HTML completa.

Indica explícitamente:

“Devuélveme solamente el fragmento de la Section, no un documento HTML completo.”

54. No agregues CSS dentro de cada elemento si puedes centralizarlo

Evita repetir:

<div style="padding:20px;border-radius:16px;">

en veinte Cards.

Puede ser más mantenible:

<div class="service-card-custom">

Y CSS:

.service-card-custom {
    padding: 20px;
    border-radius: 16px;
}

Esto facilita:

• mantenimiento;

• responsive;

• consistencia.

No significa que todo style="" sea incorrecto

pero evita repetición innecesaria.

55. No reemplaces Classes del Grid por CSS manual sin necesidad

Si tienes:

<div class="col-sm-4">

no elimines automáticamente la Class

para construir:

width: 33.333%;
float: left;

Bootstrap ya resuelve la estructura.

Aprovecha el sistema existente.

56. Grid Row desde el Editor

Recuerda que el componente Grid Row permite configurar:

• dirección;

• alineación;

• Wrap;

• columnas;

• tamaños responsive.

Antes de modificar HTML del Grid:

revisa el panel Contenido.

Puede que no necesites código.

Por ejemplo

quieres:

4 columnas

Utiliza:

Add column

No escribas manualmente todo el Row

si el editor puede hacerlo.

57. Section desde el Editor

También recuerda que Section permite configurar:

• Container width;

• Container height;

• Background;

• Overlay;

• Top Separator;

• Bottom Separator.

No escribas CSS manual

para algo que ya puedes configurar visualmente.

Ejemplo

Quieres:

Background Image

Revisa primero:

Section → Background → Image

No agregues directamente:

background-image: url(...);

sin necesidad.

58. Hover y Active desde Estilo

Antes de escribir:

.my-button:hover {
}

recuerda que Estilo permite seleccionar:

hover

Y:

active

Utiliza la herramienta visual cuando sea suficiente.

CSS manual es útil cuando necesitas un control más específico.

59. nth-of-type(2n)

El Editor también permite trabajar con:

nth-of-type(2n)

Puede resultar útil para elementos repetidos,

por ejemplo filas alternadas.

Pero no utilices este selector

si no comprendes qué elemento está seleccionando.

Puede afectar unidades inesperadas.

60. ¿Cómo probar una modificación de HTML?

Después de:

Save Changes

no continúes inmediatamente con veinte cambios más.

Primero comprueba:

• estructura;

• diseño;

• responsive;

• funcionalidad.

Por ejemplo

modificaste una Card.

Comprueba:

Desktop
Tablet
Mobile

Si contiene Link:

pruébalo.

Si contiene interacción:

utilízala.

Después continúa.

Esto facilita identificar qué cambio produjo un problema.

Cambios pequeños y progresivos

son mucho más seguros que:

50 modificaciones
↓
Guardar
↓
algo está roto

Después será difícil saber cuál causó el error.

Mejor:

Cambio 1
↓
Comprobar
↓
Cambio 2
↓
Comprobar

61. ¿Qué hacer si el elemento desaparece después de editar HTML?

Primero revisa:

• etiquetas abiertas/cerradas;

• estructura;

• parent;

• display;

• HTML que eliminaste.

Compara con la copia original.

No reconstruyas toda la página.

Si el fragmento original funciona:

restáuralo.

62. ¿Qué hacer si cambia el diseño de elementos vecinos?

Probablemente modificaste:

• wrapper;

• Row;

• Column;

• Class compartida;

• selector CSS demasiado amplio.

Utiliza Navigator.

Pregunta:

¿Modifiqué realmente la Card o modifiqué su contenedor?

Esa suele ser la causa.

63. ¿Qué hacer si desaparece una columna?

Revisa:

• Row;

• Column;

• etiquetas de cierre;

• Classes responsive.

Un:

</div>

eliminado

puede alterar toda la estructura siguiente.

HTML necesita una jerarquía correctamente cerrada.

64. ¿Qué hacer si todo se coloca uno debajo de otro?

Revisa las Classes del Grid.

Por ejemplo

si eliminaste:

col-sm-4

las columnas pueden perder su distribución.

No agregues Float inmediatamente.

Restaura la estructura correcta.

65. ¿Qué hacer si el diseño funciona desktop pero no mobile?

Revisa:

• Classes responsive;

• Width fija;

• Min Width;

• Padding;

• imágenes;

• media queries.

No utilices:

body {
    overflow-x: hidden;
}

como solución.

Eso oculta el síntoma.

No corrige la causa.

66. ¿Qué hacer si aparece scroll horizontal?

Busca especialmente:

width: 1200px

O:

min-width: 900px

O:

margin-left: 400px

O:

position

Corrige el elemento que desborda.

67. ¿Qué hacer si un cambio de CSS modificó Header o Footer?

Recuerda:

Header y Footer no se editan mediante Editor de bloques,

pero un CSS demasiado global puede alcanzar elementos fuera del bloque.

Por ejemplo:

a {
    color: red;
}

puede modificar muchos Links.

O:

img {
    width: 100%;
}

puede afectar imágenes que no pretendías tocar.

Limita el selector a tu Section.

68. ¿Qué hacer si una regla modifica todos los Buttons?

Busca:

button

O:

.btn

Puede afectar componentes globalmente.

Utiliza:

.my-section .my-button {
}

69. ¿Qué hacer si un estilo modifica todos los Links?

Busca:

a

O:

.nav-link

Especialmente importante

porque .nav-link puede intervenir en:

• Nav Bar;

• Tabs;

• navegación.

Utiliza scope.

70. ¿Qué hacer si se rompen Tabs después de editar HTML?

Revisa:

• control;

• panel;

• IDs;

• referencias;

• Classes de estado.

No agregues nuevo JavaScript.

Primero compara con el HTML original.

71. ¿Qué hacer si se rompe Accordeon?

Mismo procedimiento.

No fuerces:

display:block !important;

Eso no corrige la lógica.

Solo muestra todos los paneles.

72. ¿Qué hacer si se rompe Flip box?

Busca:

• Transform;

• Position;

• Backface;

• Overflow.

Especialmente si agregaste CSS.

No sobrescribas Transform sin revisar.

73. ¿Qué hacer si desaparecen iconos?

Busca:

font-family

Especialmente CSS sobre:

i
span

Puede haber afectado Font Icon.

74. ¿Qué hacer si imágenes cambian todas juntas?

Busca:

img {
}

O una Class compartida.

Revisa Linked styles.

Puede que el comportamiento sea intencional.

75. ¿Qué hacer si solo quiero una excepción?

Agrega:

Class adicional

Ejemplo

Todas:

product-image

Una especial:

product-image product-image-featured

CSS:

.product-image-featured {
    ...
}

No cambies el estilo base de todas.

76. ¿Qué hacer si una IA quiere reemplazar toda mi estructura?

No aceptes automáticamente.

Pídele:

Mantén el HTML existente.

Modifica únicamente:
[detalle].

No cambies:
- Classes Bootstrap;
- IDs;
- Links;
- jerarquía.

Si devuelve todo nuevamente

puedes pedir:

“Devuélveme únicamente las líneas que debo cambiar.”

O:

“Devuélveme solamente el CSS adicional.”

77. ¿Qué hacer si la IA agrega Bootstrap CDN?

Indícale:

Elimina cualquier importación de Bootstrap.

Waclis ya utiliza Bootstrap 4.

No cargues otra versión.

78. ¿Qué hacer si agrega jQuery?

Pregunta:

¿Es realmente necesario?

Si solo está haciendo:

• Hover;

• estilos;

• layout;

probablemente no.

No agregues dependencias sin motivo.

79. ¿Qué hacer si agrega JavaScript para un acordeón?

Utiliza el componente:

Accordeon

No reconstruyas funcionalidad existente.

80. ¿Qué hacer si genera una página completa?

Pide:

Devuélveme solamente el fragmento interno que puedo utilizar dentro de una Section de Waclis.

No incluyas:
DOCTYPE
html
head
body
Bootstrap CDN
jQuery CDN

Esto es especialmente importante.

81. Flujo recomendado para una modificación visual

1. SELECCIONAR ELEMENTO
↓
2. REVISAR CONTENIDO
↓
3. REVISAR ESTILO
↓
4. REVISAR AVANZADO
↓
5. SI NO ALCANZA, IDENTIFICAR CLASS
↓
6. UTILIZAR CSS LOCALIZADO
↓
7. REVISAR LINKED STYLES
↓
8. PROBAR RESPONSIVE
↓
9. GUARDAR CAMBIOS
↓
10. VER PÁGINA

82. Flujo recomendado para modificar HTML de un elemento

1. SELECCIONAR ELEMENTO
↓
2. ABRIR NAVIGATOR
↓
3. CONFIRMAR JERARQUÍA
↓
4. ABRIR <>
↓
5. COPIAR HTML ORIGINAL
↓
6. IDENTIFICAR IDS Y CLASSES
↓
7. MODIFICAR SOLAMENTE LO NECESARIO
↓
8. SAVE CHANGES
↓
9. REVISAR LIENZO
↓
10. REVISAR RESPONSIVE
↓
11. PROBAR INTERACCIONES
↓
12. GUARDAR CAMBIOS
↓
13. VER PÁGINA

83. Flujo recomendado para usar IA con HTML

1. SELECCIONAR EL ELEMENTO
↓
2. COPIAR SOLAMENTE SU HTML
↓
3. EXPLICAR EL OBJETIVO
↓
4. ACLARAR BOOTSTRAP 4
↓
5. INDICAR QUÉ NO DEBE CAMBIAR
↓
6. PEDIR PRIMERO ANÁLISIS
↓
7. REVISAR LA PROPUESTA
↓
8. PEDIR CAMBIO MÍNIMO
↓
9. PEGAR EL CAMBIO
↓
10. PROBAR

84. Flujo recomendado para utilizar Code editor

1. CONFIRMAR QUE EL CAMBIO NECESITA ALCANCE AMPLIO
↓
2. NO UTILIZARLO SI <> ES SUFICIENTE
↓
3. REVISAR ESTRUCTURA
↓
4. CONSERVAR COPIA DEL CÓDIGO QUE MODIFICARÁS
↓
5. IDENTIFICAR COMPONENTES RELACIONADOS
↓
6. REALIZAR CAMBIOS PEQUEÑOS
↓
7. COMPROBAR DESPUÉS DE CADA CAMBIO
↓
8. REVISAR RESPONSIVE
↓
9. REVISAR INTERACCIONES
↓
10. GUARDAR CAMBIOS
↓
11. VER PÁGINA

Checklist: componente Code

• Quiero mostrar código, no ejecutarlo.

• Code es más apropiado que Paragraph.

• Code es más apropiado que Preformatted para este contenido.

• El ejemplo mostrado es correcto.

• No contiene secretos.

• No contiene credenciales privadas.

• Mobile puede leerlo.

• No existe un overflow innecesario.

• Guardé los cambios.

Checklist: Preformatted

• Necesito conservar espacios o saltos.

• No estoy intentando crear una Table mediante espacios.

• Mobile se mantiene legible.

• No existe desbordamiento inesperado.

• El contenido no necesita realmente Code.

Checklist: antes de editar HTML

• Seleccioné el elemento correcto.

• Utilicé Navigator.

• Sé cuál es su padre.

• Sé cuáles son sus hijos.

• Copié el HTML original.

• Identifiqué Classes.

• Identifiqué IDs.

• Identifiqué Links.

• Identifiqué atributos funcionales.

• No estoy realizando un cambio que podría resolverse con Estilo.

• No estoy realizando un cambio que podría resolverse mediante Contenido.

Checklist: después de editar HTML

• El HTML sigue mostrando la estructura correcta.

• No desaparecieron elementos.

• No quedan Tags mal cerrados.

• No eliminé Classes necesarias.

• No eliminé IDs funcionales.

• No dupliqué IDs.

• Los Links siguen funcionando.

• Desktop se ve correctamente.

• Tablet se ve correctamente.

• Mobile se ve correctamente.

• Probé la interacción si existe.

• Utilicé Save Changes.

• Utilicé Guardar Cambios.

• Revisé mediante Ver página.

Checklist de CSS

• Intenté primero utilizar Estilo.

• El CSS manual es realmente necesario.

• Utilicé una Class específica.

• El selector tiene scope.

• No utilicé body innecesariamente.

• No utilicé h1, h2, p globalmente sin intención.

• No utilicé a globalmente.

• No utilicé img globalmente.

• No utilicé svg globalmente.

• No utilicé button globalmente.

• No utilicé iframe globalmente.

• No utilicé .active globalmente.

• No utilicé .nav-link globalmente.

• No utilicé !important como primera solución.

• Revisé Linked styles.

• Revisé responsive.

• No afecté Header o Footer accidentalmente.

Checklist de JavaScript

• La funcionalidad realmente necesita JavaScript.

• Waclis no posee ya un componente que la resuelve.

• No estoy utilizando JavaScript para estilos.

• No estoy utilizando JavaScript para un Link normal.

• No estoy agregando una librería innecesaria.

• No estoy cargando otra versión de Bootstrap.

• No estoy cargando jQuery nuevamente sin necesidad.

• Comprendo el código que voy a incorporar.

• No contiene secretos.

• Probé la funcionalidad completa.

Checklist para trabajar con IA

• Proporcioné solamente el código necesario.

• Expliqué qué elemento estoy modificando.

• Informé que Waclis utiliza Bootstrap 4.

• Expliqué exactamente el cambio.

• Indiqué qué no debe modificar.

• Le pedí no agregar librerías.

• Le pedí no agregar JavaScript si no es necesario.

• Le pedí mantener IDs y Classes funcionales.

• Le pedí CSS localizado.

• No le pedí que reescriba toda la página.

• Revisé el código antes de pegarlo.

• Guardé una copia del original.

• Probé después de aplicar el cambio.

En resumen

Dentro del Editor de bloques existen varias herramientas relacionadas con código,

pero cada una tiene un objetivo diferente.

Code

CODE
→ mostrar código al visitante

Preformatted

PREFORMATTED
→ mostrar texto conservando su disposición

Editar código HTML <>

<>
→ modificar el HTML del elemento seleccionado

Code editor

CODE EDITOR
→ trabajar con una estructura de mayor alcance

Variables / CSS

CSS
→ personalizar la apariencia mediante reglas

La regla fundamental es

utiliza siempre la herramienta de menor alcance que resuelva correctamente tu necesidad.

Si quieres cambiar texto

Contenido

Si quieres cambiar apariencia

Estilo

Si necesitas una regla avanzada

CSS

Si necesitas modificar la estructura de un elemento

Editar código HTML <>

Si necesitas trabajar sobre una estructura mucho más amplia

Code editor

Antes de modificar HTML

recuerda:

NAVIGATOR
↓
SELECCIONAR ELEMENTO
↓
COPIAR ORIGINAL
↓
IDENTIFICAR IDS / CLASSES
↓
MODIFICAR SOLO LO NECESARIO

No elimines Classes o IDs solamente porque no sabes para qué sirven

Especialmente en componentes interactivos.

Recuerda también

CLASS
→ puede compartirse

Mientras:

ID
→ debe ser único

Y en componentes interactivos

un ID además puede relacionar:

CONTROL
↔
PANEL

En CSS

evita reglas globales como:

img {
    width: 100%;
}

O:

button {
    border-radius: 30px;
}

O:

.active {
    background: red;
}

Utiliza scope:

.mi-seccion .mi-elemento {
    ...
}

Cuando utilices IA

no pidas:

“Rehaz toda mi página”

si solo necesitas:

“Cambiar el Border radius de estas Cards”

Proporciona:

• el fragmento;

• contexto;

• Bootstrap 4;

• restricciones.

Y recuerda

no debes agregar dentro de una Section:

DOCTYPE
HTML
HEAD
BODY

ni cargar otra vez:

Bootstrap
jQuery

sin una necesidad real.

Waclis ya tiene una Página web y un entorno existente.

Tu objetivo debería ser

integrarte con esa estructura, no reconstruirla dentro de cada bloque.

Finalmente

el flujo más seguro es:

HERRAMIENTAS VISUALES
↓
CSS SI ES NECESARIO
↓
HTML DEL ELEMENTO SI ES NECESARIO
↓
CODE EDITOR SOLO SI EL ALCANCE LO JUSTIFICA

Y después de cualquier modificación avanzada:

SAVE CHANGES
↓
REVISAR
↓
GUARDAR CAMBIOS
↓
VER PÁGINA
↓
PROBAR DESKTOP
↓
PROBAR TABLET
↓
PROBAR CELULAR
↓
PROBAR INTERACCIONES

No existe un segundo paso de publicación.

Guardar Cambios guarda el trabajo realizado.

La calidad de una personalización avanzada no se mide por cuánto código agregaste.

Una buena personalización utiliza:

la menor cantidad de código necesaria, con el alcance más preciso posible y sin romper las funcionalidades que ya resolvía Waclis.