Less.js: No se puede crear un radio de borde elíptico

Quería agregar un problema similar / relacionado que ocurre con la propiedad de fuente al declarar una altura de línea

.class {
    font: 13px/1.231 arial, helvetica, clean, sans-serif;
} 

debería permanecer sin cambios pero se convierte en:
.clase {
fuente: 10.560519902518276px arial, helvetica, clean, sans-serif;
}

dotless también tiene este problema (https://github.com/dotless/dotless/issues/16). Sería bueno llegar a un acuerdo sobre cómo proceder en ambos.

La solución más simple que funciona hoy en día es envolverla en una cadena literal.

 font: ~"13px/1.231 arial, helvetica, clean, sans-serif";

o incluso

 font: ~"13px/1.231" arial, helvetica, clean, sans-serif;

Entendí que uno de los objetivos de less era ser compatible con la sintaxis CSS normal. El trabajo en torno a romper esta regla.

Entiendo tu frustración. No veo una solución fácil entre la aritmética de Less y las propiedades específicas de CSS. Por ejemplo, ¿qué sucede si realmente desea especificar que la fuente tiene la mitad del tamaño, es decir,

 <strong i="6">@example</strong>: 24pt;
 .foo {
     font: normal @example/2 sans-serif;
 }

Algo tiene que comprometerse. Es cierto que puede modificar Less para que se envuelvan las conversiones.

 font: normal (@example/2) sans-serif;

pero eso rompería y haría más verbosa cualquier hoja de estilo Less existente para todos los casos solo para evitar casos que no son tan comunes para las declaraciones de taquigrafía de fuente y radio de borde. Otra opción si le preocupa el CSS existente, puede importar cualquier CSS existente en su archivo Less:

 <strong i="13">@import</strong> "legacy.css";

En este caso, la importación se realiza correctamente, pero no cambia ni convierte el CSS.

Una vez más, entiendo completamente su preocupación de que Less no es un superconjunto estricto de CSS, pero me faltan ideas obviamente mejores. ¿Tiene alguna solución potencial a este problema de sintaxis?

: +1: sobre este problema de mi parte, pero tampoco estoy seguro de una forma elegante de resolverlo que no requiera escapar de CSS válido o requerir paréntesis para activar los cálculos.

@agatronic @cloudhead Estoy trabajando en una solución para esto, pero me encantaría conocer su opinión sobre cómo cree que se debe manejar esto antes de continuar. SASS y Stylus manejan esto solo permitiendo la división entre paréntesis, todas las demás operaciones matemáticas se pueden realizar fuera de los paréntesis. Este método evitará que las futuras implementaciones de la barra inclinada de W3C también se rompan, y eliminará la necesidad de los analizadores Ratio y Shorthand. Así es como me incliné por primera vez a solucionar el problema. ¿Es esta una solución razonable para los dos?

Tenga en cuenta que este error también rompe la abreviatura de fondo CSS3 que usa la barra para separar la posición del fondo (que pueden ser palabras clave o dimensiones) del tamaño del fondo. Por ejemplo:

.foo {
    background: url(image.png) center / 1px 100px;
}

También haciendo ping a

Una sugerencia anterior fue que '/' divide y '/' es una proporción. Sería bueno obtener información de @cloudhead porque, aunque sería muy bueno

@cloudhead respondió a través de Twitter, algo mínimamente: "la solución paren parece decente"

El problema con la solución de espacios es que aún rompe CSS perfectamente válido. Desafortunadamente, la única forma de abordar esto de manera efectiva sin romper el comportamiento existente es continuar permitiendo que el CSS antiguo no se analice correctamente.

¿Qué tal una opción "temporal" para que la gente pueda disfrutar de ambos durante un período de gracia?

o

deberíamos hacer un lanzamiento justo antes de fusionar esta solución y subir un número de versión principal a 1.4 (y con suerte agregar variables en inclusiones e interpolación de nombres de propiedades, etc.

Creo que esto definitivamente sería una solución que tendría que ser parte de una versión más importante, ya que rompería el comportamiento existente. No estoy seguro de que una solución temporal (si hablamos de espacios) sea incluso razonable considerando que aún podría romper el código existente y no proporciona ningún tipo de transición limpia a la solución permanente. Esta parece una situación en la que apretar el gatillo en un lanzamiento es la mejor opción, y se puede advertir a las personas a través del registro de cambios y los documentos.

Quise mantener el comportamiento de bandera existente .. pero estoy de acuerdo contigo.

¿Tiene derechos de compromiso? Incluso si es así, podría ser mejor como una solicitud de extracción, por lo que
puedo coordinar con los lanzamientos (no tenemos planes que yo conozca)

Personalmente, creo que deberíamos tragarnos la píldora y comenzar a enumerar las operaciones matemáticas sin paréntesis como una característica obsoleta. Hay demasiados casos en los que entra en conflicto con CSS válido. @agatronic : vale la pena una discusión de Skype con @cloudhead (o en otro lugar), y odio arruinar las bibliotecas MENOS de cualquier persona, pero MENOS no debería estar arrancando y rompiendo CSS que el autor no pretendía. El analizador LESS debe proporcionar señales claras de que se necesita una operación matemática, y los paréntesis son una buena manera de hacerlo. Entre paréntesis: HACER MATEMÁTICAS. No entre paréntesis: DEJARLO SOLO.

Como fase 1 para disminuir el golpe, podríamos DEJAR de hacer matemáticas ÚNICAMENTE en los casos en que la división sea ambigua, por ejemplo, en lugares donde una barra "/" es un token válido en ese valor. Entonces, en el caso del radio del borde, si LESS no está seguro, lo deja solo. Si el autor está seguro de que quiere una división entre los dos números, puede anular el comportamiento predeterminado agregando paréntesis.

Pero, tal como está ahora, MENOS está documentado como "CSS válido = MENOS válido", y con este error, ese no es el caso. Está reescribiendo falsamente CSS válido, lo que lo convierte en un error claro. El problema es que TAMBIÉN es una operación matemática claramente documentada. Los dos están en conflicto, y me parece claro que el segundo caso es el que debería modificarse, con CSS preservado.

Veo que @ttfkam y @ mlms13 dijeron casi lo mismo. Creo que su instinto es correcto, y votaría firmemente que MENOS comience una migración lenta a paréntesis como requisito para las operaciones.

@matthewdl +1

@agatronic : No tengo derechos de compromiso, sin embargo, estoy de acuerdo en que esto debería hacerse a través de un PR de todos modos para la revisión del código y la posible coordinación de lanzamientos.

@matthewdl : Para los propósitos de mi PR, comencé a trabajar en permitir solo la división entre paréntesis. Considérelo una medida provisional para evitar que LESS rompa CSS válido. No se limita a reglas específicas, por lo que en cualquier lugar donde se encuentre una barra oblicua y no esté envuelta en parens, se generará como un dilimitador literal. Una vez hecho esto, veré un poco más cómo restringir todas las operaciones para que solo se realicen dentro de los parientes.

Bien, he hablado de esto con @cloudhead en Skype. Él está de acuerdo, así que aquí está el plan:

1) En la próxima versión, la documentación se actualizará para indicar que las matemáticas fuera de paréntesis están en desuso. La documentación demostrará que las operaciones matemáticas están entre paréntesis. Sin embargo, las matemáticas sin división fuera de paréntesis aún deberían compilarse (para esa versión).

2) En la publicación posterior al paso # 1, TODAS las operaciones matemáticas requerirán paréntesis. La documentación cambiará de "obsoleta" a "no admitida" (o algo así: se puede refinar la forma en que la comunicamos).

¿Suena bien? Esto significa que deberíamos comenzar a planificar cuáles son los hitos para las próximas 2 versiones, pero eso está fuera del alcance de este hilo aquí.

En realidad, para aclarar, la documentación se puede actualizar AHORA para decir que las matemáticas fuera de paréntesis están en desuso, ya que las matemáticas entre paréntesis funcionan bien. Así que ese es realmente el Paso 0: Actualizamos los documentos ahora para decirle a la gente: a) Las matemáticas deben estar entre paréntesis, y si no lo hacen, es posible que se rompan en el futuro, b) Demuestre todas las matemáticas entre paréntesis.

¡Funciona para mi! : +1:

así que presumiblemente @dmcass debería hacer una solicitud de extracción contra
https://github.com/cloudhead/lesscss.org

¿Y luego deberíamos molestar a @cloudhead para comprometernos o darnos derechos de compromiso para ese proyecto?

Correcto. Sí, intentaré recordar molestarlo hoy.

El 21 de agosto de 2012, a las 5:19 a.m., Luke Page [email protected] escribió:

así que presumiblemente @dmcass https://github.com/dmcass debería hacer una solicitud de extracción
en contra
https://github.com/cloudhead/lesscss.org

y luego deberíamos molestar a @cloudhead https://github.com/cloudhead para
¿Comprometernos o darnos derechos de compromiso para ese proyecto?

-
Responda a este correo electrónico directamente o véalo en
Gi tHubhttps: //github.com/cloudhead/less.js/issues/146#issuecomment -7899194.

Abrí un PR para actualizar los documentos en cloudhead / lesscss.org # 29

Corregido en maestro para 1.4.0

Será así en 1.4.0

Echa un vistazo a la versión alfa en less2css.org

Este error todavía ocurre en 1.4.1 si usa el siguiente CSS:
radio del borde

Produce:
radio del borde: 0 0100% Infinity% 0 24px 24px;

(Lo probé en http://less2css.org)

@rubious, ¿

Está bien, eso funciona, sin embargo, estoy usando LiveReload y esta opción no parece estar activada allí.

Lo siento, esa es la única forma de solucionarlo ... o active las matemáticas estrictas para que todas las matemáticas solo se hagan si están entre paréntesis O

border-radius:0 0 100% 100% ~"/" 0 0 24px 24px;