Less.js: Impossible de créer un rayon de bordure elliptique

Je voulais ajouter un problème similaire / lié qui se produit avec la propriété font lors de la déclaration d'une hauteur de ligne

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

il doit rester inchangé mais il devient:
.classer {
police: 10.560519902518276px arial, helvetica, clean, sans-serif;
}

dotless a également ce problème (https://github.com/dotless/dotless/issues/16). Ce serait bien de parvenir à un accord sur la manière de procéder dans les deux cas.

La solution la plus simple qui fonctionne dès aujourd'hui est de l'envelopper dans une chaîne littérale.

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

ou même

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

J'ai compris que l'un des objectifs de less était d'être compatible avec la syntaxe CSS normale. Le travail autour de briser cette règle.

Je comprends votre frustration. Je ne vois pas de solution simple entre l'arithmétique de Less et les propriétés CSS spécifiques. Par exemple, que se passe-t-il si vous souhaitez en fait spécifier que la police a la moitié de la taille, c'est-à-dire

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

Quelque chose doit faire des compromis. Certes, vous pouvez modifier Less pour que toutes les conversions soient encapsulées.

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

mais cela casserait et rendrait plus verbeuse les feuilles de style Less existantes pour tous les cas, juste pour éviter les cas qui ne sont pas aussi courants pour les déclarations abrégées de police et de rayon de bordure. Une autre option si vous êtes préoccupé par le CSS existant, vous pouvez importer n'importe quel CSS existant dans votre fichier Less:

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

Dans ce cas, l'importation réussit, mais ne modifie ni ne convertit le CSS.

Encore une fois, je comprends parfaitement votre inquiétude que Less ne soit pas un sur-ensemble strict de CSS, mais il me manque évidemment de meilleures idées. Avez-vous des solutions potentielles à ce problème de syntaxe?

: +1: sur ce problème de ma part, mais je ne suis pas non plus sûr d'une manière élégante de le résoudre qui ne nécessite ni d'échapper un CSS valide ni d'exiger des parenthèses pour déclencher des calculs.

@agatronic @cloudhead Je travaille sur un correctif pour cela, mais j'aimerais avoir votre avis sur la façon dont vous pensez que cela devrait être géré avant d'aller plus loin. SASS et Stylus gèrent tous deux cela en n'autorisant que la division entre parenthèses, toutes les autres opérations mathématiques peuvent être effectuées en dehors des parenthèses. Cette méthode empêchera également toute implémentation future de la barre oblique par le W3C de se rompre et supprimera le besoin des analyseurs Ratio et Shorthand. C'est ainsi que j'ai d'abord été enclin à résoudre le problème. Est-ce une solution raisonnable pour vous deux?

Notez que ce bogue casse également le raccourci CSS3 d'arrière-plan qui utilise la barre oblique pour séparer background-position (qui peuvent être des mots-clés ou des dimensions) de background-size. Par example:

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

Ping également

Une suggestion précédente était que «/» divise et «/» est un rapport. Ce serait bien d'obtenir des commentaires de @cloudhead parce que même si ce serait vraiment bien d'être trié, c'est assez effrayant si cela casse le comportement existant ...

@cloudhead a répondu via Twitter, de manière quelque peu minimale: "la solution paren semble décente"

Le problème avec la solution des espaces est qu'elle rompt toujours le CSS parfaitement valide. Malheureusement, le seul moyen de résoudre ce problème efficacement sans briser le comportement existant est de continuer à permettre à l'ancien CSS simple d'échouer correctement l'analyse.

que diriez-vous d'une option «temporaire» pour que les gens puissent profiter des deux pendant une période de grâce?

ou alors

nous devrions faire une version juste avant de fusionner ce correctif et monter un numéro de version majeur à 1.4 (et, espérons-le, ajouter des variables dans les inclusions et l'interpolation des noms de propriétés, etc.

Je pense que ce serait certainement un correctif qui devrait faire partie d'une version plus majeure, car cela briserait le comportement existant. Je ne suis pas sûr qu'une solution temporaire (si nous parlons d'espaces) soit même raisonnable étant donné qu'elle pourrait encore casser le code existant et qu'elle ne fournit aucune sorte de transition propre vers la solution permanente. Cela semble être une situation où appuyer sur la gâchette sur une version est la meilleure option, et les gens peuvent être avertis via le journal des modifications et la documentation.

Je voulais dire drapeau pour garder le comportement existant .. mais je suis d'accord avec vous.

Avez-vous des droits de validation? Même si tel est le cas, ce serait peut-être mieux comme pull request, nous
peut coordonner avec les versions (nous n'avons aucun plan à ma connaissance)

Personnellement, je pense que nous devrions avaler la pilule et commencer à répertorier les opérations mathématiques non entre parenthèses comme une fonctionnalité obsolète. Il y a trop de cas où il entre en conflit avec un CSS valide. @agatronic - Cela vaut la peine de discuter sur Skype avec @cloudhead (ou ailleurs), et je déteste ruiner les bibliothèques LESS de qui que ce soit, mais LESS ne devrait pas déchirer et casser le CSS que l'auteur n'avait pas l'intention. L'analyseur LESS doit recevoir des signaux clairs indiquant qu'une opération mathématique est nécessaire, et les parenthèses sont un bon moyen de le faire. Entre parenthèses: DO MATH. Pas entre parenthèses: LAISSEZ-LE SEUL.

En tant que phase 1 pour atténuer le coup, nous pourrions ARRÊTER de faire des maths UNIQUEMENT dans les cas où la division est ambiguë, par exemple dans les endroits où une barre oblique "/" est un jeton valide dans cette valeur. Donc, dans le cas du rayon de la bordure, si LESS n'est pas sûr, il le laisse tranquille. Si l'auteur est sûr de vouloir une division entre les deux nombres, il peut remplacer le comportement par défaut en ajoutant des parenthèses.

Mais, dans l'état actuel des choses, LESS est documenté comme «CSS valide = valide LESS», et avec ce bogue, ce n'est pas le cas. Il réécrit faussement du CSS valide, ce qui en fait un bogue clair. Le problème est que c'est ÉGALEMENT une opération mathématique clairement documentée. Les deux sont en conflit, et il me semble clair que le deuxième cas est celui qui devrait être modifié, avec CSS préservé.

Je vois que @ttfkam et @ mlms13 ont dit à peu près la même chose. Je pense que leur instinct est correct, et je voterais fortement pour que MOINS commence une lente migration vers les parenthèses étant une exigence pour les opérations.

@matthewdl +1

@agatronic : Je n'ai pas de droits de validation, mais je suis d'accord que cela devrait être fait par le biais d'un PR de toute façon pour la révision du code et la coordination potentielle de la publication.

@matthewdl : Pour les besoins de mon PR, j'ai commencé à travailler uniquement sur la division entre parenthèses. Considérez cela comme une mesure provisoire pour empêcher LESS de casser des CSS valides. Il n'est pas limité à des règles spécifiques, donc partout où une barre oblique est rencontrée et qu'elle n'est pas entourée de parens, elle sera sortie comme un dilimiteur littéral. Une fois que cela est fait, j'examinerai un peu plus comment restreindre toutes les opérations pour qu'elles ne soient effectuées que dans les parenthèses.

D'accord, j'en ai discuté avec @cloudhead sur Skype. Il est d'accord, alors voici le plan:

1) Dans la prochaine version, la documentation sera mise à jour pour que les mathématiques hors parenthèses soient obsolètes. La documentation montrera les opérations mathématiques comme étant entre parenthèses. Cependant, les mathématiques sans division en dehors des parenthèses doivent toujours être compilées (pour cette version).

2) Dans la version suivante après l'étape 1, TOUTES les opérations mathématiques nécessiteront des parenthèses. La documentation passera de "obsolète" à "non prise en charge" (ou quelque chose comme ça - comment nous la communiquons peut être affinée).

Ça sonne bien? Cela signifie que nous devrions commencer à planifier les jalons des 2 prochaines versions, mais cela sort du cadre de ce fil de discussion ici.

En fait, pour clarifier, la documentation peut être mise à jour MAINTENANT pour dire que les maths en dehors des parenthèses sont obsolètes, car les maths entre parenthèses fonctionnent bien. Donc, c'est vraiment l'étape 0: Nous mettons à jour les documents maintenant pour dire aux gens a) Les mathématiques doivent être entre parenthèses, et ne pas le faire peut casser à l'avenir, b) Démontrez tous les mathématiques entre parenthèses.

Travaille pour moi! : +1:

donc probablement @dmcass devrait faire une pull request contre
https://github.com/cloudhead/lesscss.org

et ensuite nous devrions tracasser @cloudhead pour nous engager ou nous donner des droits de validation sur ce projet?

Oh, c'est vrai. Oui, je vais essayer de me rappeler de le déranger aujourd'hui à ce sujet.

Le 21/08/2012, à 05h19, Luke Page [email protected] a écrit:

donc vraisemblablement @dmcass https://github.com/dmcass devrait faire une pull request
contre
https://github.com/cloudhead/lesscss.org

et ensuite nous devrions tracasser @cloudhead https://github.com/cloudhead pour
s'engager ou nous donner des droits d'engagement sur ce projet

-
Répondez directement à cet e-mail ou affichez-le sur
Gi tHubhttps: //github.com/cloudhead/less.js/issues/146#issuecomment -7899194.

J'ai ouvert un PR pour mettre à jour les documents sur cloudhead / lesscss.org # 29

Corrigé sur le maître pour la version 1.4.0

Ce sera comme ça dans la 1.4.0

Découvrez l'alpha sur less2css.org

Ce bogue se produit toujours dans 1.4.1 si vous utilisez le CSS suivant:
rayon de la bordure: 0 0100% 100% / 0 0 24px 24px;

Il produit:
rayon de la bordure: 0 0 100% Infinity% 0 24px 24px;

(Je l'ai essayé sur http://less2css.org)

@rubious avez-vous

OK cela fonctionne, mais j'utilise LiveReload et cette option ne semble pas être activée là-bas.

Désolé, c'est la seule façon de résoudre ce problème ... soit activez les mathématiques strictes afin que tous les calculs ne soient effectués que s'il s'agit de parenthèses OU

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