El analizador CSS analiza inválidamente ciertas declaraciones duplicadas
cuando el propio navegador ya tiene un árbol DOM y toda la información de estilo, etc., puede recuperarse bajo demanda una vez seleccionado un componente Probablemente esto es algo que he intentado construir antes de uvapesjs y, para ser sincero, tras unas semanas de trabajo me di cuenta de que el resultado era simple...
Lee la respuesta completa abajo ↓Pregunta
Probado en el último commit de la rama de desarrollo 39be1e0. Este problema ocurrió en una de mis plantillas, así que es un problema real. Me llevó alrededor de medio día crear este caso de prueba minificado, así que espero que ayude.
Si tienes una plantilla con el siguiente CSS:
<div id="gjs">
<style>
cuerpo {
familia de fuentes: Helvetica Neue;
}
cuerpo, span {
fuente: heredar;
}
cuerpo {
familia de fuentes: Helvetica Neue;
}
</style>
<span>Encontrar</span>
</div>
Un navegador lo representa correctamente de la siguiente manera:
<img width="609" alt="captura de pantalla 2018-04-20 a las 3:14:01" src="https://user-images.githubusercontent.com/331833/39075971-8307bb60-44ad-11e8-89ed-355801ac3c33.png">JSFiddle: https://jsfiddle.net/szLp8h4n/192/
Pero uvas lo representa mal:
<img width="863" alt="captura de pantalla 2018-04-20 a las 3 16 04 pm" src="https://user-images.githubusercontent.com/331833/39076015-c52c0726-44ad-11e8-8469-c6f0f327c3d9.png">JSFiddle: https://jsfiddle.net/szLp8h4n/194/
@artf este es otro ejemplo en el que recomendaría no crear tu propio analizador (aunque lo llamas "traverser"), y simplemente depender del analizador del navegador. Por ejemplo, no debería ser necesario crear una caché interna de todos los componentes y estilos, cuando el propio navegador ya tiene un árbol DOM y toda la información de estilo, etc., puede recuperarse bajo demanda una vez seleccionado un componente. Sin embargo, sería un cambio demasiado grande para las uvas hacer esto en este caso concreto. Así que en este caso recomendaría investigar la causa y arreglar este caso en particular.
¿Tienes alguna idea de qué podría causar esto? Si no tienes tiempo para arreglarlo, me gustaría hacerlo yo mismo porque es un problema urgente para mí. Pero agradecería mucho algunos consejos que me ayudaran a empezar.
¡Muchas gracias <3
Respuestas (3)
cuando el propio navegador ya tiene un árbol DOM y toda la información de estilo, etc., puede recuperarse bajo demanda una vez seleccionado un componente
Probablemente esto es algo que he intentado construir antes de uvapesjs y, para ser sincero, tras unas semanas de trabajo me di cuenta de que el resultado era simplemente un pedazo de basura grande, insostenible, poco fiable y LENTO. Créeme, Tom, mantener el estado de una aplicación tan grande dentro del DOM simplemente no es una opción. Y otra vez, estoy usando el analizador del navegador, pero el problema es cómo se construye el estado CSS de las reglas.
Por cierto, GrapesJS antes de crear una nueva regla de estilo comprueba si ya existe una, con las mismas propiedades. Si se encuentra uno, actualiza su estilo, así que esto es lo que ocurre:
- Se crea e inserta la primera declaración de 'cuerpo' dentro del estado: '''js [ Primera regla { selectores: [], // <-- este se usa solo para selectores (clases) selectoresAñadir: 'body', // Selectores adicionales estilo: {...}, } ]
2. Lo mismo para el segundo
'''js
[
Primera regla
{
Seleccionadores: [],
seleccionadores Añadir: 'cuerpo',
estilo: {...},
},
Segunda regla
{
Seleccionadores: [],
selectorsAdd : 'body, span', // diferente del anterior
estilo: {...},
}
]
- La siguiente declaración del 'cuerpo' es la misma que la primera, por lo que solo se actualizará su estilo '''js [ Primera/Tercera regla { Seleccionadores: [], seleccionadores Añadir: 'cuerpo', Estilo: {...}, // Estilo actualizado }, Segunda regla { Seleccionadores: [], seleccionadores Añaden: 'cuerpo, envergadura', estilo: {...}, } ]
Como ves, el problema aquí es que la tercera regla se inserta dentro de la primera y esto rompe el principio de cascada.
Probablemente, la solución rápida sería añadir alguna opción que ignore todas las comprobaciones y añada todas las reglas incondicionalmente.
@artf me sorprende que esto sea más lento porque pensaba que el navegador estaría muy optimizado para esto, pero definitivamente tienes más experiencia con este proyecto, así que confiaré en tu criterio ;)
Definitivamente estoy a favor de la opción de añadir todas las reglas incondicionalmente. Esto tiene sentido para mí porque para mí el navegador es la verdad y no debería haber necesidad de hacer comprobaciones adicionales además de lo que te dice el navegador.
¿Te gustaría hacer esto o debería crear un récord permanente? Si es lo segundo, ¿podría decirme dónde se hacen estas comprobaciones? ¿Está realmente en este getter que enlazaste antes? Esperaría que las comprobaciones se hicieran fuera de un receptor.
Agradecería mucho un récord personal. Creo que la comprobación estaría bien dentro del método añadir
Preguntas y respuestas relacionadas
Continúa investigando con debates sobre temas similares.
Issue #989
[BUG] Los tramos consecutivos muestran el espacio en blanco de forma diferente en el editor de uvas que en una ventana normal
He pasado la mayor parte de una tarde intentando depurar esto. Aunque he reducido esto a un caso de prueba pequeño y fácil de reproducir, a...
Issue #896
[BUG] Las reglas de consulta de medios son anuladas por las reglas de clase en el lienzo
Hola @artf, He notado un problema mientras probaba una de mis plantillas usando diferentes configuraciones de dispositivos que supuestament...
Issue #3727
Problema sobre la importación de estilos
Hola @artf, Describe el error con detalle Mientras creaba una nueva plantilla usando GrapesJS, me encontré con un escenario en el que, cuan...
Issue #4847
Las ediciones CSS no se mantienen en el DOM
Versión GrapesJS[X] Confirmo que se debe usar la última versión de GrapesJS¿Qué navegador usas? Versión de Chrome 109.0.5414.87Describe el...
Plugins de pago que cumplen con este problema
Seleccionado por temas clave y relevancia de etiquetas para ayudarte a enviar más rápido.
Cargando recomendaciones de plugins de pago...
Consulta los plugins de código abierto de GrapesJS en GitHub O haz una búsqueda rápida en nuestro catálogo gratuito.
Explora plugins gratuitos →Los plugins premium incluyen soporte, actualizaciones regulares y funciones listas para producción — ahorrando días de trabajo de integración.
Explora plugins premium →Explorar categorías de plugins
Ve directamente a las páginas de categorías de plugins en el marketplace.