Less.js: : étendre les mixins

J'aime ça, mais juste pour être clair.. cela ne vous permet pas de faire quelque chose que vous ne pouviez pas faire avant, cela signifie simplement que vous obtenez..

.navbar,
.banner {
    // clearfix stuff
}

plutôt que

.navbar {
    // clearfix stuff
}
.banner {
    // clearfix stuff
}

ou ai-je mal compris ?

J'adorerais avoir les deux, les mixins paramétriques et habituels, pour avoir

.navbar,
.banner {
    // clearfix stuff
}
.....

ou

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}
....

chaque fois que vous en avez besoin, je sais que c'est de la même manière que les mixins fonctionnent déjà, donc la question a surtout de la flexibilité et un moyen de mieux gérer la sortie CSS finale en termes d'optimisation.

sûrement

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}

est plus court que

 .clearfix {
    // clearfix stuff
  }
 .navbar{
    // clearfix stuff
 }
.banner {
    // clearfix stuff
}

et pour des exemples plus compliqués qui pourraient être critiques, et je sais que certaines personnes sont passées à SASS juste à cause de cette pénurie

Les mixins réguliers ne pouvaient pas changer. Ils sont à peu près un appareil de Less. @agatronic , oui, je le vois aussi de cette façon. Il y a cependant des défis à cela, comme serions-nous en mesure d'étendre les mixins paramétriques ? Et si oui comment cela fonctionnerait-il ? En supposant que cela soit pris en charge, disons que vous étendez deux fois un mixin paramétrique mais que vous utilisez des variables différentes à chaque fois, comme ceci :

.transition(@transition) {
  -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}
.navbar {
    &:extend(.transition(opacity .2s linear));
}
.banner {
    &:extend(.transition(opacity .3s linear));
}

J'imagine que cela pourrait créer deux copies du mixin, ce qui n'est pas moins de code, et aucun avantage par rapport aux mixins classiques :

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

Cependant, vous pouvez utiliser beaucoup ce mixin particulier, donc lorsque vous utilisez à nouveau le mixin sur .dropdown avec les mêmes variables que .banner , cela peut donner ceci :

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner,
.dropdown {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

Et c'est ce qui rend cela intéressant pour moi. ça serait bien d'avoir les retours des autres aussi

@jonschlinkert oui, c'est encore une meilleure illustration, merci. comme je l'ai dit les deux mains dessus ! mais comprenez bien que cela ajoute un autre niveau de complicité, et doit être fait/pas fait de manière réfléchie

L'extension de la méthode à laquelle vous faites référence peut être réalisée assez facilement avec ce modèle :

.transition(@transition) {
    -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}

.quickOpacity1(){
    .transition(opacity .2s linear);
}

.quickOpacity2(){
    .transition(opacity .3s linear);
}

.navbar{
    .quickOpacity1();
}

.banner,
.dropdown{
    .quickOpacity2();
}

Ce qui précède injecte des mixins semi-étendus dans les 2 nouvelles déclarations.

Pour le clearfix, il est également facile d'utiliser un modèle similaire ci-dessous, qui non seulement créera le clearfix en tant que classe, mais injectera ces styles clearfix dans une nouvelle déclaration.

.clearfix{
  //clearfix stuff
}
.navbar,
.banner {
    .clearfix;
}

@krismeister Je pense qu'il pourrait y avoir une confusion à ce sujet. Le modèle que vous décrivez n'est en réalité que des mixins imbriqués, ou un modèle d'héritage de mixin. Prolonge le travail à l'inverse de cela.

Héritage @jonschlinkert Mixin - un grand nom. Il semblait que les deux exemples ci-dessus essayaient d'hériter de la sortie du parent - ce qui est une caractéristique essentielle de l'extension. Vous êtes probablement d'accord pour dire que le résultat de mon exemple était le résultat attendu.

J'ai compris en relisant votre commentaire d'origine que vous voudriez que la sortie soit jointe dans une règle CSS. Bien qu'il ait été écrit comme 2 à l'origine.

En fait, :extend est assez génial. Je vais devenir intello, mais tout se résume à "ce qui est déplacé où". Pensez à un mixin comme "transmettre les propriétés du mixin au sélecteur qui l'a utilisé". Et pensez à :extend comme l'inverse, "transférer le sélecteur qui l'a utilisé jusqu'au mixin lui-même". Pas les propriétés du _selector, juste le sélecteur lui-même. Donc si tu as fait ça :

.some-mixin() {
    padding-top: 100px;
    background: #f7f7f7;
}


// a selector that is extending the mixin
.alert:extend( .some-mixin() ) {
    border: 1px solid #e5e5e5;
}
// another selector extending the mixin
section:extend(.some-mixin()) {
    margin: 20px 0;
}

Il en résulterait ceci :

// The selectors that extended the mixin are now where the mixin used to be.
.alert,
section {
    padding-top: 100px;
    background: #f7f7f7;
}

// And the properties of the mixin did not get copied down below
// so we saved a line or two of code.
.alert {
    border: 1px solid #e5e5e5;
}
section {
    margin: 20px 0;
}

Espérons que cela ait plus de sens. Je suis heureux d'aider à tout moment.

@agatronic , @matthewdl , @DesignByOnyx , juste une pensée, je sais que c'est une approche inhabituelle, mais en supposant qu'il n'y a pas de défis techniques à cela, et en supposant que nous autorisons une liste de sélecteurs séparés par des virgules, peut-être étendre _devrait_ ressembler davantage à un tableau . Que pensez-vous de changer la syntaxe en : :extend[N] .

Je pense que c'est aussi plus agréable pour les yeux lorsque les mixins sont étendus :

section:extend[.some-mixin(), .another-mixin()] {
    margin: 20px 0;
}

Je vais bien de toute façon, mais quelque chose semble juste avec les crochets.

@jonschlinkert - [] signifie attribut en css, pas en tableau, alors que :extend() été choisi en raison de son lien avec les pseudo sélecteurs, donc je pense fortement que les crochets normaux devraient rester.

bon point, je suis d'accord.

Je suis d'accord pour dire que les crochets ont l'air et se lisent bien, mais oui, nous devons nous en tenir à la syntaxe que nous avons déjà choisie.

pouce vers le haut pour la syntaxe extend (N), plus comme la nature CSS, même raison que @agatronic

Étendre les mixins n'est pas une mauvaise idée. Pas sûr de l'exemple de syntaxe, @jonschlinkert. Non pas que je n'aime pas ça ; En fait, je ne comprends pas ce que vous avez écrit.

Je pense que ce que vous voulez dire, c'est que vous voulez définir des classes qui "tirent" le même contenu de mixin, mais ne se répètent pas réellement dans le CSS résultant. Je n'appellerais pas cela l'extension des mixins. C'est-à-dire que vous ne modifiez pas la définition du mixin (de la même manière que la définition d'extension le ferait pour les sélecteurs), vous modifiez (étendez) en fait les classes résultantes.

Alors, corrigez-moi si je me trompe, mais votre exemple de barre de navigation / bannière / liste déroulante ne serait-il pas pris en charge par :

.navbar {
  .transition(opacity .2s linear);
}
.banner {
  .transition(opacity .3s linear);
}
.dropdown:extend(.banner) { }

C'est-à-dire étendre les cours comme vous le feriez normalement ? J'essaie juste de comprendre votre modèle d'utilisation, et l'utilisation d'extend pour les mixins semble en contradiction avec son utilisation et sa nomenclature pour étendre les sélecteurs. Pouvez-vous fournir plus de détails sur les raisons pour lesquelles vous auriez besoin / voudriez référencer le mixin dans un appel d'extension, et ne pas étendre un sélecteur faisant référence au mixin ?

C'est comme ça que je l'obtiens

SORTIE CSS FINALE SOUHAITÉE

.sometingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.anotherClass,
.anotherYetClass {
    // did something dynamic with a
}

.yetClass {
    // did something dynamic with b
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

LA FAÇON DONT VOUS DEVEZ ALLER AVEC LA VERSION ACTUELLE DE MOINS POUR OBTENIR LA SORTIE DÉSIRÉE

.somethingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass,
.anotherYetClass {
    .someMixin(a);
}

.yetClass {
    .someMixin(b);
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

MOINS DE SYNTAXE SUGGÉRÉE

.somethingShared {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass:extend(.sometingShared, .someMixin(a)) {
    // native another class code
}

.anotherYetClass:extend(.sometingShared, .someMixin(a)) {
    // native another yet class code
}

.yetClass:extend(.sometingShared, .someMixin(b)) {
    // native yet class code
}

Alors que les extensions ne peuvent être utiles que lorsque vous avez vraiment une quantité de code partagé, dans d'autres cas, l'utilisation ordinaire des mixins a la faveur.

Et juste un peu, un échantillon factice en direct, destiné à simplement jouer

http://jsbin.com/opekon/1/edit
http://jsbin.com/opekon/2/edit
http://jsbin.com/opekon/3/edit
http://jsbin.com/opekon/4/edit

comme dit, il pourrait y avoir vraiment une amélioration des performances dans certaines circonstances pour les personnes paresseuses comme moi :) pour optimiser le code LESS simplement parce qu'il est affecté davantage de flexibilité

Voici un bel article de blog sur les extensions qui couvre plusieurs choses concernant la façon dont SASS gère les extensions, et il est probablement sage pour nous d'apprendre de la façon dont d'autres ont fait cela. http://designshack.net/articles/css/semantic-grid-class-naming-with-placeholder-selectors-in-sass-3-2/

En particulier, je pense que ma proposition d'extension des mixins atteindrait essentiellement le même résultat final que les "espaces réservés" SASS, mais sans avoir à créer des classes inutiles et superflues réservées aux espaces réservés.

EDIT : oui, voici un autre article qui résume bien les espaces réservés. C'est exactement ce que je propose avec l'extension des mixins http://maximilianhoffmann.com/article/placeholder-selectors

Personnellement, je préférerais cela à toutes les autres fonctionnalités liées à l'extension. Sans question. C'est une déclaration forte, mais je pense que je ne fais pas un bon travail pour l'expliquer si les autres ne sont pas d'accord. C'est un truc assez puissant.

Je sens que SASS

 %tile {
  width: 200px;
  height: 200px;
  margin-right: 20px;
}

est égal au mixin paramétrique, conçu pour les extensions exclusivement, ce qui n'est probablement pas si mal en termes de séparation des préoccupations. mais ouais c'est CSS, et n'est-ce pas supposé être aussi simple que possible ?

@agatronic pendant que nous parlons, quelle est cette extension https://github.com/agatronic/less.js/blob/master/lib/less/tree/extend.js censée être ? a noté qu'il est déjà dans la branche principale moins. désolé pour la question noob cependant.

@dmi3y c'est la première version d'extend qui a été extraite d'une pull request prête pour 1.4.0 - elle représente le nœud d'extension

merci @agatronic , maintenant je vois combien j'ai raté ;)

@dmi3y , n'hésitez pas à continuer d'ajouter à la conversation, essayons de garder ce problème à un niveau supérieur afin que nous puissions le conclure. N'hésitez pas non plus à m'envoyer un e-mail personnellement, je suis heureux de discuter de la façon dont les mixins et les extensions fonctionnent avec vous (mes coordonnées sont sur mon profil). Aussi un commentaire rapide pour éviter toute confusion supplémentaire sur ce fil. Votre exemple :

%tile {
    width: 200px;
    height: 200px;
    margin-right: 20px;
}

C'est la syntaxe pour un "espace réservé" SCSS, qui a été implémenté dans la spécification SCSS pour accomplir quelque chose de similaire à ce que je propose avec l'extension des mixins. Mais cela n'a rien à voir avec le fait d'être paramétrique. Les mixins paramétriques sont simplement des _mixins qui acceptent des paramètres_, ce qui signifie que leurs valeurs peuvent changer à chaque utilisation.

@matthewdl

Je pense que ce que vous voulez dire, c'est que vous voulez définir des classes qui "tirent" le même contenu de mixin, mais ne se répètent pas réellement dans le CSS résultant

et

Votre exemple de barre de navigation / bannière / liste déroulante ne serait-il pas pris en charge par ...

Non, le point opératoire est raté, c'est tout le contraire. Peut-être que la confusion a été causée parce que j'ai fait l'erreur de me concentrer sur les mixins paramétriques dans mon exemple.

Donc d'abord, je pense qu'il est important de souligner que tous les mixins ne sont pas paramétriques, beaucoup sont créés pour _pas_ accepter les paramètres. Certains mixins, comme clearfix, sont utilisés encore et encore sans changer aucune variable lorsqu'ils sont utilisés. Il s'agit d'un cas d'utilisation parfait pour expliquer pourquoi l'extension des mixins serait avantageuse.

Paramétrique ou non, dans toute leur splendeur, les mixins ont un inconvénient en ce que chaque fois qu'un est utilisé, ses propriétés sont dupliquées . Laissez-moi donc essayer d'expliquer comment l'extension des mixins fonctionnerait en utilisant uniquement des "mixins normaux", et en continuant avec l'exemple que vous avez utilisé ci-dessus.

Compte tenu de votre exemple, il y a deux points complètement indépendants et sans rapport qui doivent être faits :

1. la classe de bannière apparaîtrait toujours dans le CSS compilé, qu'elle soit étendue ou non, mais si la classe de bannière était un mixin, elle n'apparaîtrait dans le CSS résultant que si elle était utilisée (soit étendue, soit mélangée). Cela seul est précieux. Et
2. Lorsque vous _étendez un mixin_, plutôt que de dupliquer les mêmes propriétés exactes encore et encore, nous copions les sélecteurs eux-mêmes à la place du mixin.

Mais ce n'est qu'un exemple. Considérez qu'à un moment donné dans Twitter Bootstrap, le mixin .clearfix() seul a été utilisé plus de 20 fois dans d'autres sélecteurs, ET il était également imbriqué dans 4 ou 5 autres mixins structurels, tels que .container-fixed() , .make-row() , et #grid > .core() . Ce qui signifie que ces mixins dupliquaient _également_ les propriétés du mixin clearfix à chaque fois qu'ils étaient utilisés. Et ce n'est pas unique à ce cadre.

Cela a-t-il plus de sens ? Ainsi, au lieu d'avoir les propriétés du clearfix mixin dupliquées plus de 20 fois, nous regrouperions les sélecteurs qui utilisent le clearfix mixin à la place du mixin lui-même, et les propriétés ne seraient déclarées qu'une seule

Et mon deuxième exemple ci-dessus s'est concentré sur la façon dont l'extension fonctionnerait avec les mixins paramétriques, donc j'espère que cela complète le tableau et a plus de sens maintenant? Sinon, les articles auxquels j'ai lié ci-dessus devraient dissiper toute confusion. L'extension des mixins est extrêmement puissante et utile et vous permettrait d'obtenir le même résultat net que l'extension des sélecteurs imbriqués, mais avec des mixins spécifiquement au lieu de tout sélecteur imbriqué. Cela vous permet d'organiser vos sélecteurs de la manière la plus susceptible de fournir les résultats souhaités et d'éviter des conséquences imprévues. @DesignByOnyx , @agatronic , @matthewdl , y a-t-il quelque chose qui me manque ou que j'oublie ici ? Que pouvons-nous faire pour dissiper la confusion ?

Merci. Je pense que je comprends le cas d'utilisation, et je pense que cette ligne le dit le mieux :

la classe de bannière était un mixin, elle n'apparaîtrait dans le CSS résultant que si elle était utilisée (soit étendue, soit mélangée)

Cela a du sens pour moi. Ce qui me bloque probablement, c'est que la syntaxe globale de :extend n'est pas encore définitive. Mais, vous faites des cas convaincants.

Je dirais qu'une fois que nous avons finalisé les blocs de sélecteur, si le comportement des mixins d'extension finit par correspondre au comportement des sélecteurs d'extension (la principale différence étant cette ligne que vous venez de dire, qu'aucun sélecteur n'est affiché dans le CSS pour une extension À MOINS qu'il y ait une première utilisation), alors c'est intuitif pour moi.

C'est-à-dire, si je pouvais aussi faire quelque chose comme ça (ou une syntaxe équivalente):

.facebook-button:extend( .button() all ) {
    border: 1px solid #e5e5e5;
}

... puis pouce levé de ma part. Mais, pour moi, tout cela dépend de quoi/comment/si nous résolvons :extend pour les sélecteurs. Mais, à part la syntaxe, en tant qu'idée de fonctionnalité, vous avez raison, c'est du bon.

@jonschlinkert merci, j'apprécie beaucoup votre approbation, et je ferai sûrement de mon mieux pour exprimer mes pensées aussi clairement que possible. Je pense que c'est assez excitant d'entendre ce qui se passe avec le développement futur et oui, d'être entendu. Vous tous, faites un travail formidable avec ça.

Oui, cet exemple, je devais être explicite avec mon post précédent.

%tile {
   width: 200px;
   height: 200px;
   margin-right: 20px;
 }

est tiré des didacticiels SASS fournis par Jon, et son objectif principal est d'éviter de supprimer la sortie en CSS des classes qui ne seraient pas utilisées. Donc, dans cet angle particulier, cela pourrait être vu comme un mixage paramétrique vide dans LESS. Lorsque vous voulez l'utiliser mais que vous ne voulez pas qu'il soit sorti dans la feuille de style de fin.

Je me lance dans cette discussion et j'aimerais apporter des éclaircissements sur le commentaire suivant :

si la classe de bannière était un mixin, elle n'apparaîtrait dans le CSS résultant que si elle était utilisée (soit étendue, soit mélangée)

Donc, en suivant un exemple de clearfix plus générique, est-ce le CSS MOINS et le CSS qui en résulte ? :

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }

    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.clearfix:before,
.clearfix:after,
.something:before,
.something:after {
    content: " ";
    display: table;
}
.clearfix:after,
.something:after {
    clear: both;
}
*/

Au départ, je m'attendais à ce que la classe .clearfix reste omise du CSS compilé. Personnellement, je n'aurais pas besoin de la classe dans le CSS compilé, car je ne l'utiliserais pas dans le balisage et ce sont des octets supplémentaires dans mon CSS. De toute façon, je n'ai pas vraiment d'opinion tranchée, mais une clarification sur ce point m'aiderait à faire de meilleurs commentaires à l'avenir. Merci.

est-ce le ... CSS résultant ? :

Je suis content que vous demandiez, mais non , seule la classe .something apparaîtrait dans le CSS résultant. Vous aviez donc raison dans votre attente initiale.

il suffit de lire le lien des espaces réservés et oui, je pense que l'extension des mixins est une meilleure et moins bonne façon de faire les choses et d'obtenir la même fonctionnalité.

Pour calrifier votre point ci-dessus

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }
    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.something:before,
.something:after {
    content: " ";
    display: table;
}
.something:after {
    clear: both;
}
*/

et probablement si la définition de .clearfix() { est .clearfix { alors l'appeler avec ou sans crochets à l'intérieur de la définition d'extension ne fera aucune différence pour la sortie.

L'utilisation de la pseudo syntaxe de classe pour la fonctionnalité d'extension est totalement FAUX,
parce que "extend sth" n'est PAS égal à "match sth", cela ne signifie rien sur la structure DOM qu'un sélecteur devrait.

Vous les gars MOINS avez "inventé" beaucoup de mauvaises idées. Le plus célèbre est "reuse" .xxx (sélecteur de classe) comme notation mixin. Au moins, cela facilite la migration du CSS simple vers le préprocesseur. Mais la syntaxe :extend est la pire idée que j'aie jamais entendue.

Je ne veux pas honorer ce genre de discours sur nos problèmes, mais ce n'est pas la première fois que j'entends ces choses, alors parlons de CSS et purifions l'air.

Vous les gars MOINS avez "inventé" beaucoup de mauvaises idées. Le plus connu est "reuse" .xxx (sélecteur de classe) comme notation mixin. .... : la syntaxe d'extension est la pire idée que j'aie jamais entendue.

.xxx est appelé un mixin implicite. Cela fonctionne et c'est facile à comprendre. En fait, cette syntaxe n'est pas aussi "invasive" sur la spécification CSS que, disons, l'utilisation de règles at pour le style actuel. @keyframes se rapproche le plus de ce qui serait décrit comme un style et pourrait _peut-être_ être considéré comme une exception à ce que je dis puisque des identifiants sont utilisés qui correspondent à la production d'identifiants dans la syntaxe CSS. Au-delà des images clés, en général, les règles CSS at sont réservées principalement à une configuration de niveau supérieur et à une manipulation de style ou de feuille de style basée sur des informations "externes", c'est-à-dire en dehors des styles eux-mêmes, comme l'encodage de caractères ( @charset ), ou répondre aux conditions spécifiques à l'appareil ( @media ).

En plus, je peux penser à des idées pires. Comme l'utilisation de règles at pour le style est l'une d'entre elles, l'utilisation de deux règles at pour la même fonctionnalité en est une autre. Bien sûr, tout dépend de vos objectifs, si vous voulez manipuler les styles par programmation sans les toucher personnellement, alors il y a probablement des avantages à utiliser des constructions grammaticales plus obtuses et évidentes qui pourraient être plus faciles à saisir pour un analyseur. On dirait que vous utilisez Stylus, donc j'aimerais connaître votre point de vue sur les raisons pour lesquelles d'autres syntaxes sont avantageuses.

"extend sth" n'est PAS égal à "match sth", cela ne signifie rien sur la structure DOM qu'un sélecteur devrait.

Correct. Les pseudo-classes avec nth _something_ sont décrites comme des pseudo-classes " 6 autres types de pseudo-classes : "dynamique", "négation", "cible", "vierge", "états d'élément UI" et "langage". Si la spécification CSS décrivait en fait une fonctionnalité "d'extension", elle pourrait se situer assez élégamment comme catégorie entre les pseudo-classes "négation" et "cible".

Les pseudo-classes permettent une sélection basée sur des informations dans l'arborescence du document, mais ce n'est probablement pas une utilisation optimale de la fonctionnalité d'extension.

Totalement faux

Une communauté qui est plus grande que tous les autres préprocesseurs combinés ne peut pas se tromper. Qu'y at-il à dire?

@hax - La pêche à la traîne sans esprit pourrait se transformer en une discussion :extend discussion :extend . Si vous avez une meilleure suggestion, croyez-moi - nous sommes tout ouïe.

Pour ajouter à @jonschlinkert , .this:not(.that) { } et .this:matches(.that) { } et .this:extend(.that) { } sont catégoriquement similaires. C'est-à-dire : « étant donné le sélecteur 'ceci', associez-le au sélecteur 'cela' d'une manière particulière." Étant donné que LESS étend souvent les concepts et la syntaxe introduits dans CSS, c'est une extension assez logique du langage. Nous prêtons une attention particulière à la spécification CSS et, par conséquent, reflétons ses particularités. S'il y a une bizarrerie dans le concept, cela commence, espérons-le, d'abord en CSS. C'est pourquoi dans nos mixin guards, "AND" est représenté par le mot "and", et "OR" est représenté par une virgule : car c'est comme ça dans les media queries. Notre objectif n'est pas de corriger ou de modifier CSS, mais de rendre CSS beaucoup plus facile à utiliser et de rendre LESS complètement familier pour les auteurs CSS. :extend est un exemple. Si vous savez utiliser :not , vous savez utiliser :extend .

Et si nous utilisions une syntaxe plus "implicite" pour éviter les parenthèses imbriquées et faciliter l'extension des mixins paramétriques ?

Aujourd'hui, nous utilisons un mixin paramétrique comme celui-ci :

.square {
  .border-radius(9px);
}

Plutôt que d'étendre le mixin comme ceci (comme vous pourriez étendre une classe normale):

.square {
  &:extend(.border-radius);
}

On pourrait s'étendre ainsi :

.box {
  .border-radius:extend(9px);
}
.square {
  .border-radius:extend(9px);
}
.rectangle {
  .border-radius:extend(4px);
}

La distinction est que le "mixin étendu" se termine par un point-virgule et déclare une valeur ou des valeurs à l'intérieur des parenthèses, .border-radius:extend(9px); , plutôt que de lister les classes à étendre à l'intérieur des parenthèses et de commencer un nouveau bloc sélecteur avec des accolades, .border-radius:extend(.some-class) {} . À mon humble avis, ce n'est pas moins subtil que les mixins implicites ( .border-radius; ), qui est l'une des fonctionnalités les plus intéressantes de LESS, encore une fois à mon humble avis.

Dans la sortie rendue, tout "mixin paramétrique étendu" serait rendu à la place du mixin d'origine, comme ceci :

.box, 
.square {
    -webkit-border-radius: 9px;
    -moz-border-radius: 9px;
    border-radius: 9px;
}
.rectangle {
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
}
.some-other-class, 
.another-class, 
.and-another {
    -webkit-border-radius: 2px;
    -moz-border-radius: 2px;
    border-radius: 2px;
}

Donc personnellement, j'aime ça parce que c'est assez d'écart par rapport à la syntaxe d'extension "normale" à l'intérieur des blocs de sélecteur pour rendre assez évident ce qui se passe, et cela va de pair avec la subtilité des conventions existantes moins où il n'est pas nécessaire de trop expliquer ce qui vous essayez d'accomplir dans le code. Cette fonctionnalité est définitivement en haut de ma liste de souhaits personnelle.

En utilisant l'exemple clearfix que j'ai donné dans ma demande d'origine, voici à quoi cela ressemblerait avec ma syntaxe révisée :

.clearfix() {
    // ...
}
.navbar {
    .clearfix:extend(); // instead of &:extend(.clearfix());
}
.banner {
    .clearfix:extend();
    &:extend(.some-class); // "implicit mixin" being extended
}

J'aime où vous allez avec ça. Je pense qu'une approche plus conviviale consiste à utiliser un :extend à la fin de la syntaxe _existing_ mixin en tant que telle :

.box {
  .border-radius(9px):extend;
}
.square {
  .border-radius(9px):extend;
}
.rectangle {
  .border-radius(4px):extend;
}

Quelque chose à propos de l'omission des parenthèses après le :extend donne l'impression que cela sert un objectif différent de celui de la syntaxe d'extension existante.

Je pourrais aller n'importe où avec cela, mais je préfère .border-radius:extend(9px); parce que c'est cohérent avec la syntaxe d'extension, IMO il est toujours évident que c'est un mixin, mais cela implique également que les paramètres/valeurs sont étendus - ce qui aidera à expliquer pourquoi la sortie est "groupée".

@jonschlinkert - à ce stade, je tiens vos opinions en très haute estime et soutiendrai toute décision que vous jugerez la meilleure. Je dirai que votre méthode donne l'impression que le 9px est passé pour "étendre" au lieu d'être passé au mixin lui-même... mais je suis d'accord avec l'un ou l'autre.

@DesignByOnyx merci pour les aimables paroles. Ce que vous dites a beaucoup de sens, mon "objectif" d'extensions (en Less) a été quelque chose comme :

.this:extend(.that) {}

votre point est donc cohérent avec mon propre point de vue. @matthewdl ou @lukeapage , l'un de vous a-t-il un point de vue/opinion à ce sujet ? Je pense que les deux syntaxes pourraient fonctionner (et probablement d'autres), mais il est vrai que je ne me suis pas concentré sur la "prestation à l'épreuve du temps" avec l'une ou l'autre syntaxe, il pourrait donc y avoir des problèmes sur l'une ou l'autre. J'aimerais juste que cela se produise, je pense que l'extension des mixins est une fonctionnalité intéressante pour Less, elle fera plus pour générer du code DRY que toute autre fonctionnalité à laquelle je peux penser pour le moment

Pourquoi le compilateur Less ne peut-il pas automatiquement « faire ce qu'il faut » ? En d'autres termes, si j'ai déclaré ce mixin dans mon code :

.someMixin {
    color: red;
}

Et puis plus tard je l'utilise comme ceci:

#someElement {
    .someMixin;
}

Pourquoi le compilateur ne peut-il pas être assez intelligent pour optimiser ce code Less dans ce CSS :

.someMixin,
#someElement
{
    color:red;
}

Pourquoi devrais-je, en tant qu'utilisateur, ajouter manuellement un mot-clé :extends pour obtenir ce comportement ? Le compilateur doit être suffisamment intelligent pour se rendre compte que cette optimisation peut être effectuée et ensuite le faire.

Personnellement, je pense que cette idée :extends est déroutante. Toute la notion de mot-clé "extends" signifie : "Prenez cette chose X et ajoutez-y A, B et C." Mais dans ce contexte, vous proposez de redéfinir les extensions en : "Cette chose X est en fait la même que Y, donc vous pouvez simplement déclarer Y et X égaux et l'écrire une fois." Cela va à l'encontre de la notion standard d'"étendre" quelque chose.

Oui, je pensais exactement à la même chose plus tôt et j'allais la poster, mais après y avoir réfléchi, j'ai décidé qu'appliquer automatiquement un "comportement d'extension" aux mixins était trop opiniâtre pour Less.js. Plus précisément, même si l'héritage de sélecteur (extension) est un concept génial qui est très bénéfique pour la réduction de code, la grande majorité des plaintes que j'ai lues à propos de la fonctionnalité est qu'elle ajoute une couche d'abstraction qui rend difficile le passage au peigne fin du code et déboguer en cas de problème.

Donc les grands esprits se rencontrent, mais je vote personnellement contre l'idée parce que a) nous ne devrions pas du tout jouer avec les mixins "normaux" jusqu'à ce que la fonctionnalité extend soit complètement stable et que la spécification soit plus complète, b) Je pense que de nombreux développeurs veulent faire cet appel pour eux-mêmes, et c) souvent, les choses semblent si évidentes et évidentes, alors que le fait est que nous oublions de nombreuses excentricités sur les mixins qui rendraient votre suggestion difficile à mettre en œuvre au minimum, et probablement impossible à mettre en œuvre tout en permettant aux développeurs d'utiliser tous les "hacks mixin" que nous avons... hum, ils ont appris à connaître et à aimer.

La syntaxe :extends() est toujours un hack assez maladroit qui n'est pas intuitif et difficile à expliquer aux nouveaux utilisateurs.

La meilleure solution consiste simplement à faire en sorte que le compilateur optimise automatiquement le CSS comme décrit ci-dessus lorsque l'utilisateur a sélectionné un style de sortie approprié (compressé, optimisé, etc.). Si l'utilisateur sélectionne le style de sortie non compressé, le compilateur doit éviter ces optimisations et générer moins de code DRY.

De plus, vous pouvez résoudre les difficultés de débogage avec les cartes source. Ils peuvent facilement indiquer l'emplacement du CSS compilé qui provient d'un mixin Less.

@bdkjones, veuillez créer une nouvelle demande de fonctionnalité pour "optimiser automatiquement le CSS" avec vos suggestions sur la façon d'accomplir cela dans le code. Ce genre de contribution est toujours la bienvenue.

Point pris ! Je ne voulais pas être aussi dur dans mon dernier commentaire ; Je m'emporte parfois.

En ce qui concerne le code, je crains d'être totalement occupé avec CodeKit. Je vous laisse hacher les langues !

Pas du tout! vraiment, j'ai vu que vous étiez impliqué dans CodeKit, j'adorerais avoir votre contribution continue. Toutes les fonctionnalités ne plairont pas à tout le monde, mais les commentaires et les opinions bien arrêtées sont les seules choses qui font tourner les roues !

@bdkjones Le problème est la cascade. Dans votre cas d'utilisation, cela fonctionne, mais le regroupement de sélecteurs n'aurait pas le résultat souhaité dans tous les cas, car il déplacerait éventuellement les sélecteurs "plus tôt" dans le document, empêchant ainsi les déclarations qui écrasaient ces sélecteurs.

Mais, je suis d'accord avec vos déclarations contre la syntaxe d'extension de mixin telle qu'elle a évolué ici. Le sélecteur X devrait étendre le sélecteur ou le mixin Y, donc cela semble étrange :

.border-radius(9px):extend;

Je pense que nous utilisons mal la syntaxe d'extension. Si la syntaxe d'extension telle qu'elle existe ne correspond pas aux mixins (ce qui est parfaitement plausible), je suggérerais que nous trouvions la bonne syntaxe pour les mixins, plutôt que d'étendre la syntaxe d'extension d'une manière qui déforme la métaphore, comme @bdkjones le souligne dehors.

Je pense que nous utilisons mal la syntaxe d'extension

Je ne suis pas d'accord. Si cela fonctionne, utilisez-le. Pourquoi créer de nouvelles syntaxes sans raison ? Je pense que nous avons un grand précédent pour la syntaxe proposée, je donne de nombreux exemples et justifications à l'appui de mes suggestions, mais votre opinion sur les syntaxes proposées semble très subjective. Et puisque vous avez fait cette déclaration plusieurs fois récemment, pouvez-vous expliquer pourquoi vous pensez que la syntaxe est maltraitée ? Ou expliquer à quel moment une syntaxe est-elle maltraitée ? Ou partagez vos réflexions sur la façon dont les mixins devraient être étendus, mais sans la syntaxe « extend » ?

Dans votre cas d'utilisation, cela fonctionne, mais le regroupement de sélecteurs n'aurait pas le résultat souhaité dans tous les cas, car il déplacerait éventuellement les sélecteurs "plus tôt" dans le document, empêchant ainsi les déclarations qui écrasaient ces sélecteurs.
...
Je pense que nous utilisons mal la syntaxe d'extension. Si la syntaxe d'extension telle qu'elle existe ne correspond pas aux mixins (ce qui est parfaitement plausible), je suggérerais que nous trouvions la bonne syntaxe pour les mixins, plutôt que d'étendre la syntaxe d'extension d'une manière qui déforme la métaphore, comme le souligne bdkjones .

Non. Il n'a rien signalé, il nous a exhortés à rendre Moins plus facile à utiliser - c'était son objectif. Sa manière suggérée de le faire était erronée, mais l'intention était bonne. Ce à quoi il ne pensait pas, c'est la cascade que vous venez de signaler. Lors de l'utilisation d'extend en général, vous devez prendre en compte la cascade. Je pense que quiconque utilise extend au lieu d'un mixin en est conscient. Ainsi, c'est pourquoi Less.js vous offre le choix de l'utiliser quand cela a du sens, ou de _pas_ quand ce n'est pas le cas. Le fait que le premier "C" en CSS signifie cascade n'annule pas l'avantage de consolider les styles en double lorsque la cascade n'est pas importante. Qu'est-ce que j'oublie ici?

Alors, pouvez-vous clarifier votre sentiment ? Êtes-vous contre cette fonctionnalité, ou la syntaxe ? Si vous êtes contre la syntaxe, merci de proposer autre chose pour faire avancer les choses, sinon n'entraînons pas la progression d'une fonctionnalité aussi prometteuse pour le langage.

Êtes-vous contre cette fonctionnalité, ou la syntaxe ?

Je suis pour la fonctionnalité, absolument. C'est une direction évidente. J'ai revu la syntaxe dans ce fil. Quelques idées:

Tout d'abord, c'est gênant pour moi:

.something:extend( .clearfix() ) { }

Les doubles parenthèses sont juste bizarres. Mais, c'est une adoption fidèle de la syntaxe d'extension existante, donc assez juste. C'est pourquoi je plaidais pour autre chose, peut-être autre chose que l'extension.

Ensuite, il y a ceci que vous avez proposé, je pense pour des raisons similaires:

.border-radius(9px):extend;

... auquel j'ai eu une réaction allergique, car cela semble contraire à la spécification d'extension existante. C'est donc là que cela m'a semblé être un abus.

MAIS

J'ai réalisé qu'il y avait en fait deux options. La première est que nous faisons quelque chose de différent pour les mixins. Mais l'autre option est que nous révisions la spécification d'extension existante, pour tout, y compris les mixins, tels que :

#namespace {
  .box-template {
    .subelement {
      // we'll add the all flag to extend everything here
    }
  }
}
.clearfix() {
  // a clearfix mixin
}
.text-shadow(@shadow) {
  -moz-text-shadow: @shadow;
  text-shadow: @shadow;
}
.some .random .selector {
  // with properties
}
.mybox {
  .clearfix:extend;
  #namespace > .box-template:extend !all;
  .text-shadow:extend(2px 2px #ff0000);
  .some .random .selector:extend;
}

Mais.... avec un sélecteur complet ( .some .random .selector ), il commence à mal lire. Il semble que juste .selector ait l'extension dessus. Et le mot "étendre" commence à se perdre, alors que c'est le mot important dans cette déclaration. Ce n'était pas le cas lorsqu'il était écrit sous la forme &:extend() (car il apparaissait au début), mais cette syntaxe semble s'effondrer avec les mixins.

Donc, je proposerais l'une de ces options:

// Migrating existing syntax, but ommitting a parens requirement when used with &:

.mybox {
  &:extend .clearfix;
  &:extend #namespace > .box-template !all;
  &:extend .text-shadow(2px 2px #ff0000);
  &:extend .some .random .selector;
}

// Adopting something similar to the SASS approach

.mybox {
  <strong i="24">@extend</strong> .clearfix;
  <strong i="25">@extend</strong> #namespace > .box-template !all;
  <strong i="26">@extend</strong> .text-shadow(2px 2px #ff0000);
  <strong i="27">@extend</strong> .some .random .selector;
}

Je pense que la discussion sur l'extension des mixins et des media queries a mis en évidence que notre approche syntaxique originale de :extend n'est pas si flexible, surtout lorsque nous voulons étendre plusieurs sélecteurs et mixins.

Je pense qu'il est important d'avoir :extend right. Si nous voulons utiliser "extend" pour les mixins, alors je pense que nous devons réviser la syntaxe d'extension.

Je n'ai pas proposé .border-radius(9px):extend; , @DesignByOnyx l'a fait. J'ai proposé .border-radius:extend(9px);

Mais l'une ou l'autre syntaxe me convient. Ou nous pourrions faire .border-radius(9px) !extend; ou .border-radius:shamallamadingdongscoobiedoo(9px):extendmyass (jk), cela n'a pas d'importance pour moi car rien ne change du tout avec le comportement des mixins ou des extensions.

Donc, je ne sais pas comment vous en arrivez à devoir faire tout cela, vous vous compliquez probablement trop les choses.

Cette demande de fonctionnalité concerne expressément la possibilité de copier les propriétés héritées d'un mixin _à la place du mixin_, et elle suivra des règles qui ont déjà été bien établies avec le comportement actuel du mixin, et ont désormais également la priorité et un comportement identique à la fonctionnalité <strong i="14">@import</strong> (reference) (que, d'ailleurs, j'utilise pas mal dans la pratique et l'amour). En un mot:

• Lorsque vous utilisez un mixin, ses propriétés sont copiées à la place du sélecteur appelant le mixin.
• Lorsque vous utilisez extend, le sélecteur _extending_ est copié à la place de la classe _extending_.
• Ainsi, lorsque vous étendez un mixin, le sélecteur appelant est copié à la place du mixin.

Je ne sais pas pourquoi vous voulez même relancer le débat sur la syntaxe pour prolonger après deux ans de débat, > 100 messages, beaucoup de recherches et l'argument a déjà été fait que c'est _beaucoup plus_ flexible que @extend .

Au fait, je ne suis pas sûr de ce que vous voulez dire ici :

avec un sélecteur complet (.some .random .selector), il commence à mal lire. Il semble que juste .selector ait l'extension dessus. Et le mot "étendre" commence à se perdre, alors que c'est le mot important dans cette déclaration.

Je ne suis pas d'accord pour dire que c'est déroutant, puisque c'est ainsi que cela fonctionne actuellement. N'est-ce pas comme dire « les développeurs CSS ne savent pas comment fonctionnent les sélecteurs groupés » ? Qu'en est-il de :hover ou :after ? Je pense que les développeurs CSS peuvent très bien comprendre cela, car cela fonctionne de la même manière que les autres pseudos.

.some .random .selector:extend(.something) {}

J'aime la flexibilité que cela offre, car je peux appliquer (ou les deux) l'extension au sélecteur, qui est .some .random .selector , pas .selector , ou je peux le ranger dans le bloc sélecteur.

Je pense que la discussion sur l'extension des mixins et des media queries

J'ai fermé le problème des requêtes de médias parce que j'ai réalisé qu'il pouvait être résolu en étendant les mixins. "Tous les chemins mènent à _____" prolongeant les mixins. ;-)

J'aimerais ajouter mes deux centimes pour dire que les parenthèses à l'intérieur d'une parenthèse - :extend( .some-mixin() ) - ne me dérangent pas vraiment, d'autant plus que :extend( .some-selector ) est déjà établi et a été discuté ad nauseam. Je suis d'accord que les doubles parents ne sont en aucun cas idéaux et cela semble un peu bizarre. Mais je pense qu'il est important que les mixins et les sélecteurs soient traités de la même manière en termes d'"extension", de la même manière qu'ils sont traités de la même manière dans less classiques :

header {
    .some-selector;
    .some-mixin;
    .some-mixin();
}

En tant que tel, je ne me sens pas vraiment trop mal (ou limité) en faisant ceci :

header {
    &:extend( .some-selector );
    &:extend( .some-mixin );
    &:extend( .some-mixin() );
}

Mais je pense qu'il est important que les mixins et les sélecteurs soient traités de la même manière en termes d'"extension", de la même manière qu'ils sont traités de la même manière dans le classique Less

Je suis sur la même longueur d'onde sur ce point.

Je ne sais pas pourquoi vous voulez même ressasser le débat sur la syntaxe pour prolonger après deux ans de débat, > 100 messages

Ce n'est pas une question de vouloir. Non, je ne veux pas. Pourtant, à l'époque, nous avons en quelque sorte mélangé les mixins pour les traiter plus tard. Je veux juste poser la question si nous sommes sûrs que cette syntaxe fonctionne de la manière dont nous voulons qu'elle fonctionne pour tout. Il n'y a rien de mal à revisiter la question si nous pensons que cela ne fonctionne pas ou que c'est inélégant pour certaines utilisations. LESS existe depuis longtemps sans s'étendre. Il est plus important de bien faire les choses que de le faire rapidement.

Alors, on est cool avec ça ?

.mybox {
  &:extend(.clearfix());
  &:extend(#namespace > .box-template all);
  &:extend(.text-shadow(2px 2px #ff0000));
  &:extend(.some .random .selector);
}

parens à l'intérieur d'un parens - :extend( .some-mixin() ) - ne me dérange pas vraiment, d'autant plus que :extend( .some-selector ) est déjà établi

Oui, c'est vrai, et en fait, nous avons déjà un précédent pour les doubles parenthèses dans Less.js également, ET avec la syntaxe d'extension existante. Et le précédent qui a déjà été créé n'est pas aussi agréable pour les yeux que ce que nous proposons avec les mixins. Actuellement, nous pouvons faire ceci :

.one:nth-child(5) {
  color: red;
}
// We can extend psuedos
.two:extend(.one:nth-child(5)) {
  background: blue;
}
// And attributes
.two:extend(.one, [hidden]) {
  width: 2px;
}

Vous trouverez même des parenthèses imbriquées dans la syntaxe CSS existante .

Nous avons donc ici à la fois la syntaxe _parens imbriqués_ et _pseudo-classe imbriquée_. Et je n'ai aucun problème avec ça, c'est clair OMI.

Je suis donc d'accord avec @DesignByOnyx , c'était ma proposition originale et cela semblait déplaisant aux autres pour une raison quelconque, alors j'essayais de trouver une autre syntaxe. Mais je suis tout à fait favorable à l'utilisation de l'ancienne syntaxe mixin normale directement dans les parenthèses de l'extension.

En fait, la syntaxe d'origine permettrait d'étendre plusieurs classes ou mixins séparés par des virgules.

.banner {
    &:extend(.clearfix(), .border-radius(4px), .alert, .navbar-fixed-top, [hidden]); 
}

Il fait le travail, et c'est serré. Aucune plainte ici.

Alors, on est cool avec ça ?

Ouais. complètement. C'est déjà comme ça en CSS. Donc je suis bon avec ça.

Ouais. complètement. C'est déjà comme ça en CSS. Donc je suis bon avec ça.

ALORS IL ARRIVERA À PASSER.

Question, je ne pense pas que nous ayons actuellement un support pour plusieurs sélecteurs dans :extend, donc je me demande où le mot-clé "all" s'insérerait dans ce format, mais cela devrait probablement faire partie d'un problème séparé.

Vous avez plaidé votre cause, M. Schlinkert. Vous auriez dû entrer dans la loi. ;)

Je ne pense pas que nous ayons actuellement un support pour plusieurs sélecteurs dans :extend

Mais nous le faisons cependant ;-) Je l'ai fait de manière intensive. Je viens de le faire plus tôt :

.global-nav {
  // Extend and override bootstrap styles
  &:extend(.navbar, .navbar-fixed-top all, .navbar-inverse); // this works, and it's pretty handy
  &.hidden:extend(.navbar.hidden) {}
  &.visible:extend(.navbar.visible) {}
  &:hover {
    background: lighten(@brand-primary, 5%);
  }
  .navbar-brand {
    padding-left: 20px; 
  }
  .navbar-nav > .active > a {
    &, &:hover, &:focus {
      background-color: darken(@brand-primary, 5%);      
    }
  }
}

Vous avez plaidé votre cause, M. Schlinkert. Vous auriez dû entrer dans la loi. ;)

Pfft, lol oh arrête toi !

Je veux juste ajouter que je pense que cette syntaxe:

.foo {
  &:extend( .bar() );
}

est super. Je ne trouve pas du tout les parenthèses gênantes.

Mais surtout, je veux juste que vous vous dépêchez pour que je puisse faire tous les trucs sympas sur lesquels je travaille dans SASS dans mon préprocesseur préféré :D

Merci pour vos commentaires, @mgerring !

+1 En attente de cette fonctionnalité. Continuez votre bon travail :)

Au message d'origine :

.clearfixed {
   // stuff
}
.clearfix() {
    &:extend(.clearfixed);
}
.navbar {
  .clearfix();
}
.banner {
  .clearfix();
}

Peut-être que cela n'a pas fonctionné au moment de la publication? Mais cela donne quelque chose de très proche de ce que vous vouliez :

.clearfixed,
.navbar,
.banner {
  // stuff
}

@aaronmw , Oui, bien sûr que votre exemple fait la même chose, mais le point clé de cette proposition est la possibilité d'étendre un mixin défini ailleurs (c'est-à-dire lorsque vous ne pouvez pas ou ne voulez pas modifier le mixin lui-même, par exemple un autre fichier, partagé bibliothèque, etc.)

Oui, selon le point de @seven-phases-max, cela peut être fait comme vous le décrivez, mais ce n'est pas idiomatique.

Bon - désolé, j'ai lu beaucoup plus de ce fil maintenant et je vois ce que nous visons. La classe "squelette" que j'ai utilisée n'est qu'un déchet dans la sortie compilée car la classe .clearfixed ne serait jamais explicitement référencée en dehors du mixin. &:extend(.clearfix()) a du sens pour moi maintenant, et c'est assez excitant. Pour l'instant, je vais m'occuper des classes squelettes qui jonchent mon CSS.

Super discussion ici !

:+1:

Alors, quand pouvons-nous nous attendre à cette fonctionnalité ? Il est très utile pour des concepts comme OOCSS de créer des constructions comme une "classe abstraite".

• décider comment nous gérons l'imbrication/la portée et le mixin par rapport à la classe normale, par exemple

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {}  //
.b:extend(.a) {}  // and if so is the output wrapped by #thing?
.b:extend(.a()) {}  // do I need special format to say extend only that mixin?

• traitons-nous les arguments ? combinons-nous des mixins avec les mêmes arguments ?
• changer en-css-visitor pour ne pas supprimer les définitions de mixin
• demandez au visiteur étendu de visiter les définitions de mixin et de créer un nouvel ensemble de règles avec la nouvelle classe

Je pense que le plus difficile est de décider _exactement_ comment cela devrait fonctionner.

décider comment nous gérons l'imbrication/la portée et le mixin par rapport à la classe normale, par exemple

J'essaierais d'interpréter l'extension mixin de cette façon:
.b:extend(.a(1, 2, 3)) {} devrait se comporter de la même manière que la création d'un mixin anonyme non paramétrique (c'est-à-dire un simple sélecteur) dans la portée de 'b' qui appelle .a(1, 2, 3) intérieur puis étendu de la manière habituelle, c'est-à-dire ceci :

.a(<strong i="11">@a</strong>, <strong i="12">@b</strong>, @c) {
    // ...
}

.b:extend(.a(1, 2, 3)) {}

doit être égal à ceci :

.a(<strong i="16">@a</strong>, <strong i="17">@b</strong>, @c) {
    // ...
}

#__anon_a_1_2_3 {.a(1, 2, 3);}

.b:extend(#__anon_a_1_2_3) {}

sauf qu'aucun #__anon_a_1_2_3 n'apparaît dans la sortie. Je pense qu'une telle approche devrait la rendre moins ou plus simple sans inventer de règles spéciales.

Ainsi, en appliquant le concept ci-dessus à l'exemple #thing .a nous obtenons ce qui suit :

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {} // since we do ignore parens on mixin call and have ...
// no plans changing this (?), it should probably create .b {color: black} 

.b:extend(.a) {}  // there's only one .a in this scope so it's -> .b {color: green}

.b:extend(.a()) {}  // same as above -> .b {color: green}

D'un autre côté, les "parenthèses facultatives" sont une chose assez mineure d'un point de vue pratique, il pourrait donc également être acceptable de la rendre plus stricte et d'exiger des parenthèses pour les mixins paramétriques à l'intérieur de extend (il n'y a pas de pression sur extend pour hériter de la syntaxe d'appel simple de mixin car elle ne sera pas entièrement compatible de toute façon).

combinons-nous des mixins avec les mêmes arguments ?

Idéalement oui, sinon cela rendra le tout inutile, par exemple :

.b:extend(.a()) {}
.c:extend(.a()) {}

devrait créer :

.b, .c {color: green}

Hmm, il semble que la fusion sera la chose la plus difficile à mettre en œuvre.

Un autre problème est la portée, comme récemment soulevé dans #1730, les mixins utilisent le chemin de portée « relatif » et l'extension utilise « absolue », nous obtenons donc une sorte de conflit lorsque nous combinons les deux :

.div {color: green}

body {
   .div {color: red}

   p-a       {.div()}    // -> body p-a {color: red}
   p-b:extend(.div)   {} // -> body p-b {color: green}
   p-c:extend(.div()) {} // -> ???
}

Et c'est encore plus déroutant si nous réécrivons cet exemple avec des mixins paramétriques.

J'aimerais offrir mes deux cents pour dire que cela pourrait être le bon moment pour prendre du recul et dire "comment utiliser les mixins étendus " - et je pense que

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
}

Je ne pense pas que nous devrions nous concentrer sur les situations où un utilisateur voudrait faire ce qui suit :

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
    .tail:extend( .leg() ) { 
        .toes { display:none; } 
    }
}

Non seulement il s'agit d'un scénario marginal IMO, mais l'utilisateur doit quand même écrire ses styles comme ceci :

.dog() {
    .leg, .tail { ... }
    .ears { ... }
    .fur { ... }
    .tail .toes { display:none; }
}

Le cas d'utilisation de 99,8% pour étendre les mixins est de permettre aux développeurs d'avoir leurs bibliothèques LESS massives pleines de styles qu'ils ont accumulés au fil des ans. Cette bibliothèque massive sera pleine de choses telles que:

.clearfix() { ... }
.modal() { ... }
.alert-box() { 
    &:extend( .modal() ); 
    &.message { ... } 
    &.warning { ... } 
    &.error { ... } 
}
.grid-wrap() { ... }
.form-input() { ... }
.form-select() { ... }
.button( <strong i="16">@bgColor</strong>, <strong i="17">@textColor</strong> ) { ... }
[... thousands more like this ...]

Et ils pourraient se concentrer sur les styles d'écriture :

.page-wrap:extend( .grid-wrap(), .clearfix() ) { ... }
input[type="text"]:extend( .form-input ) { ... }
textarea:extend( .form-input() );

Ils pourraient même le faire, s'ils le voulaient et aucun des styles "modaux" ne serait même présent dans la sortie finale car ils ne sont pas utilisés dans ce projet :

.inline-error:extend( .alert-box.error )

Oui, j'ai l'impression que @DesignByOnyx a

@DesignByOnyx et @calvinjuarez, nous ne pouvons pas le comprendre plus tard.. il doit être codé d'une manière ou d'une autre. Si nous sautons sur une solution et décidons de la modifier plus tard, nous introduisons des changements de rupture, ce qui n'est pas bon.

si nous pouvons élaborer une approche qui ne prend pas en charge les scénarios marginaux, je suis plus qu'heureux, c'est un peu ce que nous avons fini par faire avec le support d'extension principal (il peut être étendu par plus de mots-clés, si nécessaire), mais nous avons besoin d'un plan pour ce qui est pris en charge et comment.

@seven-phases-max dans la veine ci-dessus, je serais heureux d'ignorer les mixins paramétriques pour le moment.

Hmm, il semble que la fusion sera la chose la plus difficile à mettre en œuvre.

• mais c'est fusionner ? J'utiliserais la même approche que les extensions existantes, par exemple, elle trouve une correspondance et l'ajoute. cas dans son genCSS

Je pense également que le deuxième exemple de @seven-phases-max sur la portée est très susceptible d'affecter quelqu'un - vous avez juste besoin d'un mixin et d'un mixin paramétrique vide du même nom.

@lukeapage :+1: C'est vrai, je peux creuser ça. Bon appel.

En fait, je pense que @seven-phases-max a raison. Alors :+1: là aussi.

@lukeapage - Je n'essayais pas de préconiser un type de solution "d'une manière ou d'une autre" mais plutôt une approche qui (comme vous l'avez dit) ne prend pas en charge les cas marginaux. En fait, nous avons déjà dépassé la capacité de portée "locale" et sommes entrés dans la phase "trop ​​tard pour revenir en arrière" IMO car :extend fonctionne comme ceci :

.block { color: green; }

.component {
  .block { color: red; }    
  div:extend( .block ) {};
}

/*
.block,
.component div {
  color: green;
}
.component .block {
  color: red;
}
*/

Je ne vois aucune raison pour laquelle le code suivant devrait fonctionner différemment de ce qui précède - l'avantage étant qu'il n'y a pas .block classe

.block() { color: green; }

.component {
  .block() { color: red; }  
  div:extend( .block() ) { };
}

/*
.component div {
  color: green;
}
*/

D'ailleurs, il y a une légère dérive dans nos conventions de nommage :) par exemple pour moi un "mixins paramétriques" signifie tout mixin défini avec des parenthèses, y compris ceux avec 0 paramètres (c'est- .mixin() {} dire que .mixin {} dire .mixin() {} était appelé un mixin "non paramétrique"), mais ...
Ne manquez pas que dans la documentation, un simple sélecteur est également nommé "mixin" (dès qu'il est mélangé) et qu'il s'agit également d'un mixin "non paramétrique" par conception. Ainsi, se référer à .mixin() {} comme à un "non paramétrique" uniquement peut être assez ambigu (techniquement, la différence réside dans la présence ou l'absence de parenthèses de définition et non dans le nombre d'arguments).
OK, c'était mon bobo habituel. :)

@lukeapage

Je serais heureux d'ignorer les mixins paramétriques pour le moment.

C'est-à-dire qu'il ne prend pas en charge l'extension pour les mixins avec des paramètres non nuls ? Je suis d'accord avec ça. J'essayais juste d'estimer comment cela pourrait être mis en œuvre (de manière unifiée sans délimiter les mixins à paramètres nuls et non nuls, afin que ce ne soit pas un obstacle quand / si ces derniers interviennent éventuellement).

mais c'est fusionner ? J'utiliserais la même approche que les extensions existantes, par exemple, elle trouve une correspondance et s'y ajoute.

D'accord, je suppose que là, je pensais davantage aux difficultés possibles avec la fusion d'extensions de mixins avec des arguments réels. : par exemple :

.b:extend(.a(1, 2, 3)) {}
.c:extend(.a(1, 2, 3)) {}

D'un autre côté, je soupçonne qu'il y a aussi des surprises cachées avec les mixins à zéro paramètre, par exemple :

.a {color: red}
.a {width: 2px}

.b:extend(.a) {}   // creates two `.b` blocks (it is expected since there're two `.a` blocks anyway)

.c {.a}            // creates one `.c` block (OK, this is just how mixins work)

.d() {color: blue}
.d() {width: 10px}

.e {.d()}          // creates one `.e` block (OK, this is just how mixins work)

.f:extend(.d()) {} // tada! another room for complains if this creates two `.f` blocks :)

Eh bien, peut-être que cela va trop loin (et aussi trop mineur pour s'en préoccuper pour le moment).

.f:extend(.d()) {} // tada! another room for complains if this creates two .f blocks :)

En pensant que « puisque, dans cet exemple, .d() est paramétrique, il ne devrait pas créer deux blocs .f » ?

Oui, je peux voir votre point, étant donné qu'un mixin entraînerait:

.f {
  color: #0000ff;
  width: 10px;
}

IMHO S'il est logique de le faire par étapes, expliquez peut-être simplement cela, mais je ne mettrais pas en œuvre quelque chose pour éviter une plainte en soi. Bien sûr, ce n'est que mon 2c. Et s'il est implémenté avec le comportement que vous avez décrit, vous pourriez - au moment de l'ajout de la fonctionnalité - également créer une demande de fonctionnalité pour "fusionner des blocs CSS à partir de sélecteurs étendus", juste pour éviter les plaintes... ?

mais je ne mettrais pas en œuvre quelque chose pour éviter une plainte en soi.

Je suis absolument d'accord. J'essaie juste de prédire toutes les surprises qui pourraient devenir l'une de ces "trop ​​tard pour changer" davantage.

:+1: ouais, j'aime ce que tu penses !

J'aime que cette discussion soit toujours en cours. Permettez-moi de revenir sur certains des points de cette discussion. Premièrement, en ce qui concerne l'usage général, cela a été égal.

.mixin {} == .mixin() {}

À l'exception du fait que .mixin { } est affiché en tant que classe. Je sais que dans l'analyseur, ils sont probablement traités différemment, mais dans l'utilisation, ils vident les paires propriété/valeur.

Sens:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    .mixin1;
    foo:bar;
}
.use2 {
    .mixin2;
    foo:bar;
}

En raison de cette histoire de syntaxe Less, il est logique que je puisse faire ceci:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use2 {
    &:extend(.mixin2);
    foo:bar;
}

Pour moi, ce n'est pas controversé, car nous avons souvent parlé de :extend en remplacement de nombreuses instances d'utilisation originale de mixin.

Pour le profane, ce serait probablement intuitivement identique, car .mixin1 peut historiquement être référencé de la manière suivante, qu'il soit ou non écrit avec des parenthèses :

.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}

Donc je m'attendrais à ça :

.mixin1() {
    color: red;    
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}
.use2 {
    &:extend(.mixin1());
    bar:foo;
}

...pour sortir...

.use1, .use2 {
    color: red;    
}
.use1 {
    foo:bar;
}
.use2 {
    bar:foo;
}

Si mixin est défini deux fois, il est remplacé deux fois lorsqu'il est étendu, tout comme son frère, le sélecteur de classe.

.mixin1() {
  color: red;
}
.mixin1() {
  width: 30px;
}
.use1 {
  &:extend(.mixin1);
  foo: bar;
}
.use2 {
  &:extend(.mixin1);
}
//output

.use1, .use2 {
  color: red;
}
.use1, .use2 { 
  width: 30px;
}
.use1 {
  foo: bar;
}

C'est essentiellement ainsi que fonctionne extend maintenant si vous supprimiez les parenthèses sur les définitions du mixin, sauf, bien sûr, que le nom du mixin apparaîtrait dans la sortie, il serait donc logique de suivre le comportement d'extension existant.

Avec les paramètres (mon cas d'utilisation à 90%), même chose, sauf qu'ils sont différenciés par entrée :

.col(@width) {
  width: @width;
  display: table-cell;
}

.col1:extend(.col(10%)) { }
.col2:extend(.col(10%)) { }
.col3:extend(.col(80%)) { }

//output 

.col1, .col2 {
  width: 10%;
  display: table-cell;
}
.col3 {
  width: 80%;
  display: table-cell;
}

Pour moi, la raison d'étendre les mixins est de regrouper des paramètres, ce qui conduit à des bibliothèques de mixins plus puissantes qui peuvent produire une sortie très concise. Les utiliser pour des mixins sans paramètres n'est pas si important, car je pourrais simplement utiliser les fonctionnalités Less existantes aujourd'hui pour produire le résultat souhaité.

Merci à tous de continuer à faire avancer ce dossier. Je pense que cela pourrait être un ajout assez puissant.

:+1 Merci @matthew-dean pour la ventilation complète - je suis d'accord avec tout ce que vous avez couvert. Pourriez-vous donner votre avis sur ce scénario, qui est l'un des sujets de discussion récents :

.mixin() { color: red; }

.component {
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

La façon dont LESS fonctionne actuellement, seuls les mixins dans la portée globale sont étendus - ce qui signifie que les styles rouges seraient étendus. Personnellement, je suis d'accord avec ce comportement, et bien que quelqu'un écrive probablement le code ci-dessus et s'attende à ce que les styles bleus prévalent, je pense que le comportement "global" d'extend est une ligne unique dans la documentation.

// this is ".mixin()", which is being extended
.mixin() { color: red; }

.component {
    // this is ".component .mixin()", which is not. 
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

Je pense que le comportement "global" d'extend est une ligne dans la documentation.

Entièrement d'accord. Je pense que c'est une très mauvaise idée d'introduire une zone grise ici.

Pour moi, c'est la cohérence qui est importante. Si le comportement actuel n'étend pas les sélecteurs dans la portée locale, il ne le devrait pas non plus avec les mixins. Si nous étendons plus tard les sélecteurs en local, les mixins devraient également le faire. Les gens devraient pouvoir faire confiance à un modèle de :extend qui est à l'échelle de la bibliothèque.

(Bien que j'aurais pu dire plus concis : "+1 au commentaire de

À ce stade, quelqu'un peut-il fournir un cas d'utilisation qui rendrait cette fonctionnalité déroutante ? Veuillez commencer par cet aperçu complet de @matthew-dean et les réponses par la suite et essayez de proposer une situation réelle qui n'a pas été couverte.

Joyeuses fêtes. Joyeux Noël. Felices Fiestas !

Vraiment belle vue d'ensemble. Je suis d'accord avec @matthew-dean et tous les commentaires suivants. :+1:

Je suis également d'accord avec @matthew-dean. Il a l'air d'un gros bonhomme et j'aimerais lui serrer la main.

(-Anonyme)

Mot de @matthew-dean. :+1:

Nous pourrions rendre le code du système de grille de Bootstrap tellement plus propre avec cette fonctionnalité !

:+1: d'accord @cvrebert ! serait sympa !

Juste à revoir. Je pense que nous avons presque un consensus et que nous avons juste besoin d'une mise en œuvre, n'est-ce pas ?

J'essaie de trouver plus d'informations à ce sujet, mais c'est comme un labyrinthe qui parcourt tout. Cela a-t-il déjà été mis en œuvre? Si c'est le cas, quelqu'un peut-il m'indiquer la zone appropriée dans la documentation.

@josh18 Non, lorsqu'une demande de fonctionnalité est toujours ouverte, cela signifie généralement qu'elle n'est pas implémentée.

Ok merci, j'ai pensé que je vérifierais juste au cas où il me manquerait quelque chose.

Je prévois à un moment donné de résumer les fonctionnalités ouvertes / à mettre en œuvre dans le Wiki, mais je n'ai pas encore eu le temps.

Je prévois à un moment donné de résumer les fonctionnalités ouvertes / à mettre en œuvre dans le Wiki, mais je n'ai pas encore eu le temps.

@matthew-dean +1

Salut les gars! Autant que je sache, cette fonctionnalité sera quelque peu similaire aux espaces réservés SASS. Je voulais juste savoir quand cela sera-t-il mis en œuvre?

Salut,
J'ai du mal à prédire mon temps et les autres contributeurs juste
mettre en œuvre des choses qui les intéressent, donc je ne suis pas sûr. Tout ce que je peux dire c'est
que nous le considérons comme une priorité élevée, c'est la prochaine grande chose sur ma liste.

Merci pour votre réponse. J'ai hâte de voir cela mis en œuvre et fonctionner. :)

+1 pour cette fonctionnalité. C'est extrêmement utile pour réduire la taille CSS.

+1 pour cette fonctionnalité.

+1 pour cette fonctionnalité.

+1 à regarder avec intérêt, merci !

:+1:

cela fait DEUX ANS que ce numéro a été créé. Balise de haute priorité depuis novembre 2014. Le jalon est 1.6.0 ou 2.0.0. Super. Moins est 2,5 maintenant.

@Grawl

Vous voulez dire que vous êtes prêt à faire un PR ?

@seven-phases-max C'est à peu près ce que je pensais. Une telle démonstration de droit. ;)

@seven-phases-max lol non je suis juste frontend/designer.
@Celc a l' air vraiment pas mal 😅

cela fait DEUX ANS que ce numéro a été créé.

Ouais, pour quoi je vous paie, de toute façon ? ;-)

Malheureusement, je ne peux pas aider avec la participation, mais je vote fortement cette demande !

Il s'agit d'une fonctionnalité extrêmement importante pour créer des cadres complexes et efficaces

3 ans et plus. Heureusement, Sass v4 arrive (avec des fonctions préfixées sass-* ) et je peux me débarrasser de Less.

@stevenvachon Nous n'avons aucune rancune contre Sass. Bien sûr, ce sont des concurrents dans un sens, mais les projets ont une philosophie différente et essayer de nous nuire en les invoquant est insensé.

Bien sûr, les demandes de tirage sont les bienvenues, de la part de n'importe qui. Nous fusionnerons volontiers en pull request fonctionnel avec cette fonctionnalité.

Je n'essaie pas de blesser qui que ce soit, en fait j'essaie probablement de l'empêcher. Je pense qu'il est préférable d'exprimer ce que l'on peut ressentir et les nouvelles directions qu'ils peuvent prendre en conséquence. Je pense qu'il vaut mieux savoir plus tôt que plus tard ; avant que tout le monde ne parte. Par exemple, Bootstrap v4 n'utilisera pas Less.js et je suis sûr que cela mettra un gros coup à votre base d'utilisateurs. Vous pouvez ignorer une telle politique autant que vous voulez, bien sûr.

@stevenvachon pourquoi si hors-sujet ? Sass et Less sont tous les deux géniaux. J'aime le JS pur de moins. node-sass a besoin d'un compilateur ac pour être installé, ce qui peut être pénible selon l'environnement. J'ai utilisé la fonctionnalité :extend qui est déjà intégrée à LESS et qui répond à tous mes besoins. Je ne sais même pas pourquoi ce problème est toujours ouvert.

Zut, je suis un développeur de rails et j'utilise gulp+LESS quand ce n'est pas un projet ruby.

Hors sujet? Cette fonctionnalité n'a pas été implémentée depuis 3 ans et ce serait très utile.

Je préférerais que Sass soit écrit en JS, mais ce n'est pas le cas, et ce n'est pas ce qui est le plus important. Ses caractéristiques sont. Sass nous permet d'étendre les espaces réservés mais Less ne nous permet pas d'étendre les mixins.

Mec, ce n'est pas du tout hors-sujet, mais une fonctionnalité très attendue! (Même si je préférerais moins de toute façon, pour diverses raisons)

Cela ne demande qu'à être fait.

PS Dans mon cas, je suis en fait un concepteur avec juste une certaine connaissance de js, principalement des trucs liés à dom, vraiment loin d'un développeur qui peut contribuer à la base de code less.js .. Ce qui est une triste histoire de toute façon)

Juste un partisan extrêmement intéressé du projet)

Message d'intéret public

À tout moment, vous pouvez soumettre une pull request ou travailler avec un développeur pour en obtenir une, et il est très probable que cette fonctionnalité soit fusionnée. La bibliothèque Less.js a besoin de contributions plus régulières d'individus comme les personnes de ce fil. . Ce n'est pas la responsabilité de n'importe qui. Cela dépend entièrement du fait qu'une personne voit ce fil, ou a besoin de cette fonctionnalité, et prend le temps de la réaliser.

Si votre réponse est que vous n'êtes pas un développeur, il existe de nombreuses AUTRES façons de soutenir ce projet dans des rôles non liés au développement, qu'il s'agisse de fournir la documentation nécessaire pour de nouvelles fonctionnalités, ou de concevoir un support sur le site Web, d'exécuter des tests, de fournir des commentaires sur les problèmes, la gestion de projet, répondre aux questions sur Stack Overflow, écrire des articles de blog, tweeter sur Less, contribuer aux communautés CSS et Web et écrire les bibliothèques Less.

Beaucoup de ces tâches sont effectuées par des personnes qui sont des développeurs, de sorte que le temps qu'elles pourraient contribuer au développement est consacré à ces autres tâches.

Si vous _êtes_ un développeur et que votre réponse est : "Je n'ai pas le temps", alors c'est la raison exacte pour laquelle ce problème est resté ouvert. C'est à vous de décider à 100% si une fonctionnalité est terminée, donc demander pourquoi elle n'a pas été complétée par "quelqu'un" n'est pas utile. _Vous êtes ce quelqu'un._ Cela arrivera, je _garantie_ que cela arrivera, si et quand vous vous impliquez dans ce projet. Vous pouvez vous impliquer dans l'un des outils open source les plus populaires sur le Web. Vous pouvez faire une différence dans la vie de... des milliers ? Des centaines de milliers? Des millions? Et comme avantage secondaire, vous pouvez vous assurer que vos fonctionnalités préférées se produisent le plus tôt possible.

Si vous voulez que cela ou n'importe quelle fonctionnalité se produise, faites-le . Nous serions très heureux de vous recevoir. Nous serions ravis de travailler avec vous ! Moins peut continuer à s'améliorer au fur et à mesure que cette communauté grandit !

Et, écoutez, j'apprécie que parfois les gens n'aient absolument pas le temps de contribuer et pourtant aimeraient vraiment qu'une fonctionnalité particulière se produise. C'est très bien. Je dirais simplement que si vous êtes dans ce scénario, vous visez l'empathie et la gratitude pour les personnes qui donnent de leur temps (et parfois de l'argent) pour vous aider, et je suis sûr que d'autres personnes de la communauté Less feront de leur mieux pour continuer à le faire, comme ils le peuvent.

Sincèrement,
Matthew Dean, membre de l'équipe principale de Less.js

Je soutiens déjà mes propres projets et j'écoute leurs demandes de fonctionnalités. Honnêtement, je n'ai pas le temps de creuser dans le noyau de Less.js.

Pour ceux qui viennent ici pour la prise en charge des espaces réservés sass (ou "classe silencieuse"), lisez ce commentaire . Cela ne vous mènera pas jusqu'au bout (en raison de #1851 et du fait que ces classes ne figurent pas dans un fichier "référencé"), mais c'est mieux que rien.