Less.js: : تمديد الخلطات

يعجبني ذلك ، ولكن فقط لأكون واضحًا .. هذا لا يسمح لك بفعل شيء لم يكن بإمكانك فعله من قبل ، فهذا يعني فقط أنك تحصل عليه ..

.navbar,
.banner {
    // clearfix stuff
}

بدلا من

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

أو قد أسأت الفهم؟

أود الحصول على كلا المزيجين البارامتريين والمعتاد

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

أو

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

كلما احتجت ، أعلم أن هذه هي الطريقة المحاكاة لكيفية عمل mixins بالفعل ، لذا فإن السؤال في الغالب يتمتع بالمرونة والطريقة للتعامل بشكل أفضل مع مخرجات CSS النهائية من حيث التحسين.

بالتاكيد

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

أقصر من

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

وللحصول على أمثلة أكثر تعقيدًا قد تكون حاسمة ، وأنا أعلم أن بعض الأشخاص قد تحولوا إلى SASS لمجرد هذا النقص

لا يمكن أن تتغير الخلطات العادية. هم إلى حد كبير لاعبا اساسيا من أقل. agatronic ، نعم أرى الأمر بهذه الطريقة أيضًا. ومع ذلك ، هناك تحديات لهذا الأمر ، مثل هل سنتمكن من توسيع الخلطات البارامترية؟ وإذا كان الأمر كذلك فكيف سيعمل ذلك؟ بافتراض أن هذا كان مدعومًا ، لنفترض أنك قمت بتمديد mixin حدودي مرتين ولكنك تستخدم متغيرات مختلفة في كل مرة ، مثل هذا:

.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));
}

أتخيل أنه قد يُنشئ نسختين من المزيج ، وهو رمز لا يقل عن ذلك ، ولا يوجد ميزة على الخلطات العادية:

.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;
}

ومع ذلك ، يمكنك استخدام هذا المزيج المحدد كثيرًا ، لذلك عند استخدام المزيج مرة أخرى على .dropdown مع نفس المتغيرات مثل .banner ، فقد ينتج عن ذلك:

.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;
}

وهذا ما يجعل هذا مثيرًا للاهتمام بالنسبة لي. سيكون من الجيد سماع تعليقات من الآخرين أيضًا

jonschlinkert نعم ، هذا توضيح أفضل ، شكرًا لك. كما قلت بكلتا يديه على ذلك! لكن عليك أن تفهم على الرغم من أنها تضيف مستوى آخر من التواطؤ ، وتحتاج إلى القيام بها / عدم القيام بها بعناية

يمكن تحقيق الامتداد في الطريقة التي تشير إليها بسهولة تامة باستخدام هذا النمط:

.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();
}

ما ورد أعلاه يقوم بحقن الخلطات شبه الممتدة في الإعلانين الجديدين.

بالنسبة لـ clearfix ، من السهل أيضًا استخدام نمط مشابه أدناه ، والذي لن يؤدي فقط إلى إنشاء clearfix كفئة ، بل سيضخ أنماط clearfix هذه في إعلان جديد.

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

krismeister أعتقد أنه قد يكون هناك ارتباك في هذا الشأن. النمط الذي تصفه هو في الحقيقة مجرد مزيج متداخل ، أو نمط وراثة mixin. يمتد العمل في معكوس ذلك.

@ jonschlinkert وراثة Mixin - اسم رائع. يبدو أن كلا المثالين أعلاه حيث تحاول وراثة الإخراج من الأصل - وهي ميزة أساسية للتمديد. ربما توافق على أن ناتج المثال الخاص بي كان ناتجك المتوقع.

أتفهم من إعادة قراءة تعليقك الأصلي ، ولكنك ترغب في دمج الإخراج في قاعدة CSS واحدة. على الرغم من أنه كتب على أنه 2 في الأصل.

في الواقع :extend رائع جدًا. سأذهب الطالب الذي يذاكر كثيرا ، ولكن كل ذلك يعود إلى "ما يتم نقله إلى أين". فكر في مزيج مثل "نقل خصائص المزيج إلى المحدد الذي استخدمه". وفكر في :extend أنه معكوس ، "إرسال المحدد الذي استخدمه إلى المزيج نفسه." ليست خصائص _selector ، فقط المحدد نفسه. لذلك إذا فعلت هذا:

.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;
}

سينتج عن هذا:

// 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;
}

نأمل أن يكون هذا أكثر منطقية. يسعدني تقديم المساعدة في أي وقت.

agatronic ، matthewdl ، DesignByOnyx ، مجرد فكرة ، أعلم أن هذا نهج غير عادي ، ولكن بافتراض عدم وجود تحديات تقنية لهذا الأمر ، وبافتراض أننا نسمح بقائمة محددة بفاصلة ، فربما يتم تمديد _should_ أن تشعر وكأنها مصفوفة . ما رأيك في تغيير بناء الجملة إلى: :extend[N] .

أعتقد أنه من الأسهل للعيون أيضًا عند تمديد الخلطات:

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

أنا بخير في كلتا الحالتين ، لكن شيئًا ما يبدو صحيحًا بشأن الأقواس المربعة.

jonschlinkert - [] تعني سمة في css ، وليس مصفوفة ، حيث تم اختيار :extend() بسبب ارتباطها بالمحددات الزائفة ، لذلك أعتقد بشدة أن الأقواس العادية يجب أن تبقى.

نقطة جيدة ، أوافق.

أوافق على أن الأقواس تبدو لطيفة وتقرأ بشكل جيد ، ولكن نعم علينا الالتزام بالصياغة التي اخترناها بالفعل.

ممتاز لبناء الجملة (N) ، يبدو أكثر مثل طبيعة CSS ، نفس السبب مثلagatronic

تمديد الخلطات ليست فكرة سيئة. لست متأكدًا من مثال بناء الجملة ،jonschlinkert. ليس لأنني لا أحب ذلك ؛ أنا فقط في الواقع لا أفهم ما كتبته.

أعتقد أن ما تقصده هو أنك تريد تحديد الفئات التي "تسحب" نفس محتوى mixin ، لكن لا تكرر في الواقع في CSS الناتج. لن أسمي هذا الخلطات الممتدة. أي أنك لا تغير تعريف mixin (بنفس الطريقة التي يفعل بها التعريف الموسع للمحددات) ، فأنت تقوم بالفعل بتغيير (تمديد) الفئات الناتجة.

لذا ، صححني إذا كنت مخطئًا ، لكن لن يتم دعم مثال شريط التنقل / البانر / القائمة المنسدلة من خلال:

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

أي تمديد الفصول كما تفعل عادة؟ أنا أحاول فقط أن ألتف رأسي حول نمط الاستخدام الخاص بك ، ويبدو أن استخدام الامتداد للمزيج يتعارض مع استخدامه وتسمياته لتوسيع المحددات. هل يمكنك تقديم مزيد من التفاصيل حول سبب احتياجك / الرغبة في الإشارة إلى mixin في مكالمة موسعة ، وعدم تمديد المحدد الذي يشير إلى mixin؟

هكذا فهمت

ناتج CSS النهائي المطلوب

.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
}

الطريقة التي يجب أن تتبعها مع الإصدار الحالي الأقل للحصول على الإخراج المطلوب

.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
}

يقترح أقل سياق

.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
}

في حين أن الامتدادات قد تكون مفيدة فقط عندما يكون لديك بالفعل كمية من الكود المشترك ، إلا أنه في حالات أخرى يكون استخدام mixins العادي صالحًا.

وإلى حد ما ، عينة وهمية حية ، تهدف إلى مجرد اللعب

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

كما قيل ، يمكن أن يكون هناك حقًا زيادة في الأداء في ظروف معينة للأشخاص الكسالى مثلي :) لتحسين رمز LESS لمجرد أنه يتأثر بمزيد من المرونة

إليك منشور مدونة لطيف حول الامتدادات التي تغطي العديد من الأشياء المتعلقة بكيفية امتداد مقابض SASS ، وربما يكون من الحكمة بالنسبة لنا أن نتعلم من كيفية قيام الآخرين بذلك. http://designshack.net/articles/css/semantic-grid-class-naming-with-placeholder-selectors-in-sass-3-2/

على وجه الخصوص ، أعتقد أن اقتراحي لتوسيع الخلطات سيحقق بشكل أساسي نفس النتيجة النهائية مثل "العناصر النائبة" لـ SASS ، ولكن دون الحاجة إلى إنشاء فئات عناصر نائبة غير مجدية وزائدة عن الحاجة فقط.

تحرير: نعم ، هنا منشور آخر يلخص العناصر النائبة بشكل جيد. إنه بالضبط ما أقترحه مع تمديد الخلطات http://maximilianhoffmann.com/article/placeholder-selectors

أنا شخصياً أفضل هذا فوق كل الميزات الأخرى ذات الصلة بالتمديد. بدون سؤال. هذا بيان قوي ، لكنني أعتقد أنني لا أقوم بعمل جيد في شرحه إذا لم يوافق الآخرون. هذه أشياء قوية جدا.

أشعر أن SASS

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

يساوي مزيج البارامترية ، المصمم من أجل الامتداد حصريًا ، ما قد لا يكون سيئًا من حيث فصل الاهتمامات. ولكن هذا هو CSS ، أليس من المفترض أن يكون بسيطًا قدر الإمكان؟

agatronic بينما نتحدث ، ما هو هذا الامتداد https://github.com/agatronic/less.js/blob/master/lib/less/tree/extend.js المفترض أن يكون؟ لاحظ أنه موجود بالفعل في الفرع الرئيسي أقل. آسف لسؤال noob رغم ذلك.

@ dmi3y هو الإصدار الأول من التمديد الذي تم سحبه من طلب سحب جاهز لـ 1.4.0 - يمثل عقدة التمديد

شكرا لك agatronic ، الآن أرى كم فاتني ؛)

@ dmi3y ، لا تتردد في مواصلة الإضافة إلى المحادثة ، دعنا نحاول إبقاء هذه المشكلة في مستوى أعلى حتى نتمكن من استنتاجها. لا تتردد أيضًا في مراسلتي عبر البريد الإلكتروني شخصيًا ، ويسعدني مناقشة كيفية عمل mixins وتوسيع نطاق العمل معك (معلومات الاتصال الخاصة بي موجودة في ملف التعريف الخاص بي). أيضا تعليق سريع لتجنب المزيد من الالتباس حول هذا الموضوع. مثالك:

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

هذا هو بناء الجملة لـ "عنصر نائب" لـ SCSS ، والذي تم تنفيذه في مواصفات SCSS لإنجاز شيء مشابه لما أقترحه مع تمديد الخلطات. لكن هذا لا علاقة له بكونه حدوديًا. الخلطات البارامترية هي ببساطة _ميكسات تقبل المعلمات_ ، مما يعني أن قيمها يمكن أن تتغير في كل مرة يتم استخدامها.

تضمين التغريدة

أعتقد أن ما تقصده هو أنك تريد تحديد الفئات التي "تسحب" نفس محتوى mixin ، ولكن لا تكرر في الواقع في CSS الناتج

و

ألن يتم دعم مثال شريط التنقل / البانر / القائمة المنسدلة بواسطة ...

لا ، تم تفويت النقطة العملية ، ولكن العكس هو الصحيح. ربما كان سبب الارتباك هو أنني ارتكبت خطأ التركيز على الخلطات البارامترية في مثالي.

لذلك أولاً ، أعتقد أنه من المهم تحديد أنه ليست كل الخلطات معلمية ، فقد تم إنشاء العديد من أجل _لا_ قبول المعلمات. يتم استخدام بعض المزيجات ، مثل clearfix ، مرارًا وتكرارًا دون تغيير أي متغيرات عند استخدامها. هذه حالة استخدام مثالية لماذا يكون تمديد الخلطات مفيدًا.

حدودي أم لا ، في كل مزيج مجدهم له جانب سلبي في أنه في كل مرة يتم فيها استخدام واحد ، تتكرر خصائصه . لذا اسمحوا لي أن أحاول أن أشرح كيف سيعمل تمديد الخلطات باستخدام "الخلطات العادية" فقط ، والاستمرار في المثال الذي استخدمته أعلاه.

بالنظر إلى مثالك ، هناك نقطتان مستقلتان تمامًا وغير مرتبطين يجب توضيحهما:

1. ستظل فئة banner تظهر في CSS المترجمة سواء تم تمديدها أم لا ، ولكن إذا كانت فئة banner عبارة عن mixin ، فإنها ستظهر فقط في CSS الناتجة إذا تم استخدامها (إما ممتدة أو مختلطة). هذا وحده ذو قيمة. و
2. عندما تقوم بتوسيع mixin ، بدلاً من تكرار نفس الخصائص الدقيقة مرارًا وتكرارًا ، فإننا نقوم بنسخ المحددات الفعلية نفسها إلى مكان mixin.

لكن هذا مجرد مثال واحد. ضع في اعتبارك أنه في مرحلة ما في Twitter Bootstrap ، تم استخدام mixin .clearfix() وحده أكثر من 20 مرة داخل محددات أخرى ، كما تم تضمينه أيضًا داخل 4 أو 5 مزيج هيكلي آخر ، مثل .container-fixed() ، .make-row() ، و #grid > .core() . مما يعني أن هذه الخلطات كانت _أيضًا _ تكرر خصائص مزيج clearfix في كل مرة تم استخدامها. وهذا ليس فريدًا في هذا الإطار.

هل هذا أكثر منطقية؟ لذلك بدلاً من تكرار خصائص clearfix mixin أكثر من 20 مرة ، سنقوم بتجميع المحددات التي تستخدم clearfix mixin في مكان mixin نفسه ، وسيتم الإعلان عن الخصائص مرة واحدة فقط. ومرة أخرى ، هذا مجرد مزيج واحد ، تخيل الفائدة الصافية من زيادة فقد الخلطات العادية ، مقابل تكرار خصائصها. كما ذكرت في مكان ما أعلاه ، سيظل من الضروري استخدام الخلطات العادية دون أن يتم تمديدها في بعض الأحيان ، من أجل الخصوصية والتجاوزات ، لكن هذا لا يقلل من قيمة تمديد الأنواع التي لا تفعل ذلك. في الواقع ، سأقوم شخصيًا بإنشاء خلطات إضافية لاستخدامها على وجه التحديد مع الامتداد ، ولن أستخدمها بخلاف ذلك.

وركز المثال الثاني أعلاه على كيفية التمديد الذي سيعمل مع الخلطات البارامترية ، لذا آمل أن يكمل هذا الصورة ويجعلها أكثر منطقية الآن؟ إذا لم يكن الأمر كذلك ، فيجب أن توضح المقالات التي ربطتها أعلاه أي لبس. يعد تمديد المزيج قويًا ومفيدًا للغاية ويسمح لك بتحقيق نفس النتيجة الصافية مثل توسيع المحددات المتداخلة ، ولكن مع mixins على وجه التحديد بدلاً من أي محددات متداخلة. يتيح لك ذلك تنظيم المحددات الخاصة بك بطريقة من المرجح أن توفر النتائج التي تريدها ، وتجنب العواقب غير المقصودة. DesignByOnyx ، agatronic ، matthewdl ، هل هناك أي شيء مفقود أو

شكرا. أعتقد أنني أفهم حالة الاستخدام ، وأعتقد أن هذا السطر يقول ذلك بشكل أفضل:

كانت فئة banner عبارة عن مزيج لن تظهر إلا في CSS الناتج إذا تم استخدامها (إما ممتدة أو مختلطة)

هذا يبدو منطقيا بنسبة إلي. من المحتمل أن ما أتعلق به هو أن بناء الجملة الإجمالي :extend لم يكن نهائيًا بعد. لكنك تقدم حالات مقنعة.

أود أن أقول أنه بمجرد الانتهاء من كتل المحدد ، إذا انتهى سلوك تمديد mixins إلى مطابقة سلوك المحددات الموسعة (مع الاختلاف الرئيسي هو ذلك السطر الذي قلته للتو ، أنه لا يوجد محدد ناتج في CSS لفترة ممتدة ما لم يكن هناك استخدام أولي) ، فهذا أمر بديهي بالنسبة لي.

هذا هو ، إذا كان بإمكاني فعل شيء مثل هذا (أو بناء جملة مكافئ):

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

... ثم رفع الإعجاب مني. لكن بالنسبة لي ، كل ذلك يعتمد على ماذا / كيف / إذا حللنا :extend للمحددات. لكن ، بغض النظر عن التركيب اللغوي ، كفكرة ميزة ، فأنت على حق ، إنه سليم.

jonschlinkert شكرًا لك ، أقدر كثيرًا موافقتك ، وبالتأكيد سأبذل قصارى جهدي لوضع أفكاري بأكبر قدر ممكن من الوضوح. أعتقد أنه من الجيد جدًا سماع ما يجري في التطوير المستقبلي ونعم ، أن يتم الاستماع إليه. أنتم جميعًا ، قم بعمل رائع مع ذلك.

نعم ، في هذا المثال ، كان علي أن أكون صريحًا في مشاركتي السابقة.

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

مأخوذ من دروس SASS التي قدمها جون ، والهدف الرئيسي منها هو تجنب نقل المخرجات في CSS من الفئات التي لن تكون قيد الاستخدام. لذلك في هذه الزاوية بالذات يمكن رؤيتها كخليط حدودي فارغ في LESS. عندما تريد استخدامه ولكن لا تريده تم إخراجه في ورقة الأنماط النهائية.

أنا أشارك في هذه المناقشة وأود توضيح التعليق التالي بنفسي:

إذا كانت فئة الشعارات عبارة عن مزيج ، فستظهر فقط في CSS الناتجة إذا تم استخدامها (إما ممتدة أو مختلطة)

لذا ، من خلال استخدام مثال clearfix أكثر عمومية ، هل هذا هو CSS الأقل والنتيجة ؟:

.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;
}
*/

كنت أتوقع في الأصل أن تظل فئة .clearfix محذوفة من CSS المترجمة. أنا شخصياً لن _أحتاج_ إلى الفصل في CSS المترجم ، لأنني لن أستخدمه في الترميز وهي وحدات بايت إضافية في CSS الخاص بي. ليس لدي رأي قوي في كلتا الحالتين ، لكن توضيح هذه النقطة سيساعدني في تقديم تعليقات أفضل للمضي قدمًا. شكرا.

هل هذا هو ... الناتج CSS ؟:

أنا سعيد لأنك تسأل ، ولكن لا ، فقط فئة .something ستظهر في CSS الناتج. لذلك كنت محقًا في توقعاتك الأصلية.

ما عليك سوى قراءة رابط العناصر النائبة ونعم أعتقد أن تمديد عمليات المزج هو أفضل وأقل طريقة للقيام بالأشياء والحصول على نفس الوظيفة.

لتهدئة نقطتك أعلاه

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

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

ويفترض أنه إذا كان تعريف .clearfix() { هو .clearfix { فإن استدعائه مع أو بدون أقواس داخل التعريف الموسع لن يحدث فرقًا في المخرجات ..

يعد استخدام بناء جملة الفئة الزائفة لميزة التوسيع أمرًا خاطئًا تمامًا ،
نظرًا لأن "extension sth" لا يساوي "match sth" ، فهذا لا يعني شيئًا عن بنية DOM التي يجب أن يقوم بها المحدد.

لقد "اخترع" العديد من الأفكار السيئة يا رفاق. الأكثر شهرة هو "إعادة استخدام" .xxx (محدد الفئة) كتدوين mixin. على الأقل يسهل الانتقال من CSS العادي إلى المعالج المسبق. لكن: توسيع بناء الجملة هو أسوأ فكرة سمعتها على الإطلاق.

لا أريد أن أحترم هذا النوع من التشدق في قضايانا ، لكن هذه ليست المرة الأولى التي أسمع فيها هذه الأشياء ، لذلك دعونا نتحدث عن CSS وننظف الأجواء.

لقد "اخترع" العديد من الأفكار السيئة يا رفاق. الأكثر شهرة هو "إعادة استخدام" .xxx (محدد الفئة) كتدوين mixin ....: بناء الجملة الموسع هو أسوأ فكرة سمعتها على الإطلاق.

يسمى .xxx بالمزج الضمني. إنه يعمل ، ومن السهل فهمه. في الواقع ، فإن بناء الجملة هذا ليس "غازيًا" في مواصفات CSS مثل ، على سبيل المثال ، استخدام قواعد at للتصميم الفعلي. @keyframes الأقرب إلى ما يمكن وصفه بأنه تصميم ويمكن اعتباره استثناءً لما أقوله نظرًا لاستخدام المعرفات التي تتطابق مع إنتاج المعرف في بنية CSS. بعيدًا عن الإطارات الرئيسية ، بشكل عام ، يتم حجز قواعد CSS at في الغالب للتكوين ذي المستوى الأعلى ومعالجة النمط أو ورقة الأنماط بناءً على معلومات "خارجية" ، بمعنى خارج الأنماط نفسها ، مثل ترميز الأحرف ( @charset ) ، أو الاستجابة للظروف الخاصة بالجهاز ( @media ).

إلى جانب ذلك ، يمكنني التفكير في أفكار أسوأ. مثل استخدام قواعد at للتصميم أحد هذه القواعد ، واستخدام قاعدتين at لنفس الميزة هو أمر آخر. بالطبع ، كل هذا يتوقف على أهدافك ، إذا كنت ترغب في التلاعب بالأساليب برمجيًا دون لمسها شخصيًا ، فمن المحتمل أن تكون هناك مزايا لاستخدام تراكيب نحوية أكثر وضوحًا ومنفرجة قد يكون من السهل على المحلل التقاطها. يبدو أنك تستخدم Stylus ، لذلك أنا مهتم بسماع وجهة نظرك حول سبب فائدة التركيبات الأخرى.

"extension sth" لا يساوي "match sth" ، فهذا لا يعني شيئًا عن بنية DOM التي يجب على المحدد أن يفعلها.

صيح. يتم وصف الفئات الزائفة التي تحتوي على nth _something_ على أنها فئات زائفة " هيكلية " حسب مواصفات CSS. ومع ذلك ، هناك 6 أنواع أخرى من الفئات الزائفة: "ديناميكي" و "نفي" و "هدف" و "فارغ" و "حالات عنصر واجهة المستخدم" و "لغة". إذا وصفت مواصفات CSS في الواقع ميزة "ممتدة" ، فيمكنها أن تقع بأناقة كفئة بين الفئتين الزائفة "النفي" و "الهدف".

تسمح الفئات الزائفة بالاختيار بناءً على المعلومات الموجودة في شجرة المستند ، ولكن ربما لا يكون هذا هو الاستخدام الأمثل لميزة التوسيع.

خاطئ تماما

لا يمكن أن يكون المجتمع الأكبر من جميع المعالجات الأخرى مجتمعة مخطئًا. ماذا يمكن أن يقال؟

hax - يمكن أن يتحول التصيد الطائش إلى مناقشة مثقفة إذا اقترحت الحل الخاص بك مثل أي شخص آخر في :extend . بعد أسابيع من الاقتراحات المختلفة والمداولات بين مطوري الواجهة الأمامية ذوي الخبرة العالية والمستخدمين الكثيرين لـ LESS ، توصلنا إلى حل مرض باستخدام بناء الجملة :extend . إذا كان لديك اقتراح أفضل ، صدقني - كلنا آذان.

للإضافة إلى jonschlinkert ، فإن .this:not(.that) { } و .this:matches(.that) { } و .this:extend(.that) { } متشابهان بشكل قاطع. وهذا هو: "بالنظر إلى المحدد" هذا "، اربطه بالمحدد" ذلك "بطريقة معينة." نظرًا لأن LESS غالبًا ما يوسع المفاهيم والبنية المقدمة في CSS ، فهو امتداد منطقي جدًا للغة. نحن نولي اهتمامًا وثيقًا لمواصفات CSS ، ونتيجة لذلك ، نعكس خصائصها. إذا كان هناك غرابة في المفهوم ، فمن المأمول أن يبدأ في CSS أولاً. لهذا السبب في حراس mixin لدينا ، يتم تمثيل "AND" بالكلمة "و" ، ويتم تمثيل "OR" بفاصلة: لأن هذا هو الحال في استعلامات الوسائط. هدفنا ليس إصلاح CSS أو تغييره ، ولكن جعل CSS أسهل بكثير في العمل معه ، وجعل LESS مألوفًا تمامًا لمؤلفي CSS. مثال على ذلك :extend . إذا كنت تعرف كيفية استخدام :not ، فأنت تعلم كيفية استخدام :extend .

ماذا لو استخدمنا صيغة أكثر "ضمنية" لهذا لتجنب أقواس متداخلة ولجعل من الأسهل تمديد الخلطات البارامترية؟

اليوم ، نستخدم مزيجًا حدوديًا مثل هذا:

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

بدلاً من تمديد المزيج على هذا النحو (حيث يمكنك تمديد فصل دراسي عادي):

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

يمكننا أن نمدّد مثل هذا:

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

التمييز هو أن "المزيج الموسع" ينتهي بفاصلة منقوطة ويعلن قيمة أو قيمًا داخل الأقواس ، .border-radius:extend(9px); ، بدلاً من سرد الفئات لتوسيعها داخل الأقواس وبدء كتلة محدد جديدة بأقواس معقوفة ، .border-radius:extend(.some-class) {} . IMHO ، هذا ليس أقل دقة من الخلطات الضمنية ( .border-radius; ) ، والتي تعد واحدة من أروع ميزات LESS ، مرة أخرى IMHO.

في الإخراج المعروض ، سيتم عرض أي "مزيج حدودي موسع" في مكان mixin الأصلي ، مثل هذا:

.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;
}

لذلك أنا شخصياً أحب هذا لأنه يكفي للخروج عن بناء الجملة الموسع "الطبيعي" داخل كتل المحدد لجعل ما يحدث واضحًا بما فيه الكفاية ، وهو يتماشى مع دقة الاصطلاحات الأقل الموجودة حيث لا توجد حاجة إلى المبالغة في شرح ما تحاول تحقيقه في الكود. هذه الميزة هي بالتأكيد على رأس قائمة أمنياتي الشخصية.

باستخدام مثال clearfix الذي قدمته في طلبي الأصلي ، هذا ما سيبدو عليه بناء الجملة المعدل:

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

أنا أحب إلى أين أنت ذاهب مع هذا. أعتقد أن الأسلوب الأكثر ودية هو استخدام :extend في نهاية بناء جملة mixin الموجود على النحو التالي:

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

شيء ما يتعلق بحذف الأقواس بعد :extend يجعلك تشعر أنه يخدم غرضًا مختلفًا عن الصيغة الموسعة الحالية.

يمكنني أن أذهب بأي طريقة مع هذا ، لكنني أفضل .border-radius:extend(9px); لأنه يتوافق مع بناء الجملة الموسع ، IMO لا يزال من الواضح أنه مزيج ، لكنه يشير أيضًا إلى أن المعلمات / القيم يتم تمديدها - مما سيساعد في التوضيح لماذا يتم "تجميع" الإخراج.

jonschlinkert - عند هذه النقطة أقدر

DesignByOnyx شكرا على الكلمات الرقيقة. ما تقوله منطقي جدًا ، "عدستي" الممتدة (في أقل) كانت شيئًا مثل:

.this:extend(.that) {}

لذا فأنت تتفق وجهة نظري. matthewdl أو lukeapage هل لديكم أي رأي / رأي حول هذا؟ أعتقد أن كلا الصيغتين يمكن أن تعمل (وربما أخرى) ، لكنني أعترف أنني لم أركز على "تدقيق المستقبل" مع أي من الصيغ ، لذلك قد يكون هناك بعض المشاكل في أي منهما. أود فقط أن أرى هذا يحدث ، أعتقد أن تمديد عمليات الخلط هو ميزة مثيرة لـ Less ، وسوف يفعل المزيد لإنشاء كود DRY أكثر من أي ميزة أخرى يمكنني التفكير فيها في الوقت الحالي

لماذا لا يستطيع المترجم الأقل تلقائيًا "القيام بالشيء الصحيح"؟ بمعنى آخر ، إذا تم التصريح عن هذا المزيج في الكود الخاص بي:

.someMixin {
    color: red;
}

وبعد ذلك أستخدمه على النحو التالي:

#someElement {
    .someMixin;
}

لماذا لا يكون المترجم ذكيًا بما يكفي لتحسين هذا الرمز الأقل في CSS هذا:

.someMixin,
#someElement
{
    color:red;
}

لماذا يتعين علي ، بصفتي المستخدم ، إضافة الكلمة الرئيسية: extends يدويًا للحصول على هذا السلوك؟ يجب أن يكون المترجم ذكيًا بما يكفي لإدراك أن هذا التحسين يمكن القيام به ثم القيام بذلك.

أنا شخصياً أعتقد أن هذا: توسيع الفكرة أمر محير. المفهوم الكامل للكلمة الرئيسية "يمتد" يعني: "خذ هذا الشيء X وأضف إليه A و B و C." لكن في هذا السياق ، تقترح إعادة تعريف الامتداد ليشمل: "هذا الشيء X هو في الواقع نفس Y ، لذلك يمكنك فقط إعلان Y و X متساويين وكتابته مرة واحدة." هذا يتعارض مع المفهوم القياسي المتمثل في "تمديد" شيء ما.

نعم ، كنت أفكر في نفس الشيء بالضبط في وقت سابق وكنت سأقوم بنشره ، ولكن بعد التفكير في الأمر قررت أن تطبيق "السلوك الموسع" تلقائيًا على الخلطات هو رأي مفرط في Less.js. على وجه التحديد ، على الرغم من أن وراثة المحدد (التمديد) هي مفهوم رائع ومفيد للغاية لتقليل الكود ، فإن الغالبية العظمى من الشكاوى التي قرأتها حول الميزة هي أنها تضيف طبقة من التجريد تجعل من الصعب التمشيط من خلال الكود وتصحيح الأخطاء عند وجود مشاكل.

تفكر العقول العظيمة على حد سواء ، لكنني رفضت الفكرة شخصيًا لأن أ) لا ينبغي لنا العبث مع مزيج "عادي" على الإطلاق حتى تصبح ميزة extend مستقرة تمامًا وتكون المواصفات أكثر اكتمالًا ، ب) أعتقد أن العديد من المطورين يريدون إجراء هذه الدعوة لأنفسهم ، و ج) في كثير من الأحيان تبدو الأشياء واضحة جدًا وجافة ، في حين أن حقيقة الأمر هي أننا ننسى الكثير من الانحرافات حول الخلطات التي من شأنها أن تجعلك اقتراح صعب التنفيذ على الأقل ، وربما من المستحيل تنفيذه مع استمرار تمكين المطورين من استخدام جميع "الاختراقات mixin" التي لدينا ... مهم ، لقد عرفوها وأحبوها.

لا يزال بناء الجملة: extends () عبارة عن اختراق أخرق جدًا وغير بديهي ويصعب شرحه للمستخدمين الجدد.

الحل الأفضل هو ببساطة جعل المترجم يقوم تلقائيًا بتحسين CSS كما هو موضح أعلاه عندما يختار المستخدم نمط إخراج مناسب (مضغوط ، محسن ، إلخ). إذا اختار المستخدم نمط الإخراج غير المضغوط ، فيجب على المترجم تجنب هذه التحسينات وإنشاء كود جاف أقل.

بالإضافة إلى ذلك ، يمكنك حل صعوبات التصحيح باستخدام خرائط المصدر. يمكنهم بسهولة الإشارة إلى موقع CSS المترجم الذي يأتي من Less mixin.

bdkjones ، يرجى إنشاء طلب ميزة جديدة لـ "تحسين CSS تلقائيًا" مع اقتراحاتك حول كيفية تحقيق ذلك في الكود. هذا النوع من المدخلات مرحب به دائمًا.

أخذت النقطة! لم أقصد أن أكون شديد القسوة في تعليقي الأخير ؛ أنا أنجرف في بعض الأحيان.

بالنسبة إلى الكود ، أخشى أنني مشغول تمامًا بـ CodeKit. اسمح لكم يا رفاق بتجزئة اللغات!

لا على الاطلاق! حقًا ، رأيت أنك تتعامل مع CodeKit ، وأحب أن أحصل على مساهمتك المستمرة. لن ترضي جميع الميزات الجميع ، ولكن التعليقات والآراء القوية هي الأشياء الوحيدة التي تحافظ على دوران العجلات!

bdkjones المشكلة هي

لكنني أتفق مع تصريحاتك ضد بناء جملة mixin الموسع كما تطورت هنا. يجب أن يقوم المحدد X بتمديد المحدد أو mixin Y ، لذلك يبدو هذا غريبًا:

.border-radius(9px):extend;

أعتقد أننا نسيء استخدام بناء الجملة الموسعة. إذا كانت الصيغة الموسعة كما هي لا تتناسب مع mixins (وهو أمر معقول تمامًا) ، فإنني أقترح أن نجد الصيغة الصحيحة للمزيجات ، بدلاً من توسيع بناء الجملة بطريقة تشوه الاستعارة ، كما يشير bdkjones خارج.

أعتقد أننا نسيء استخدام بناء الجملة الموسعة

أنا أعترض. إذا نجح ، استخدمه. لماذا إنشاء صيغ جديدة بدون سبب؟ أعتقد أن لدينا سابقة عظيمة للنحو المقترح ، وأعطي أمثلة كثيرة وأسبابًا داعمة وراء اقتراحاتي ، لكن رأيك في الصيغ المقترحة يبدو غير موضوعي للغاية. وبما أنك قد أدليت بهذا البيان عدة مرات مؤخرًا ، هل يمكنك شرح سبب اعتقادك أن بناء الجملة يتم إساءة استخدامه؟ أو شرح في أي نقطة يتم إساءة استخدام بناء الجملة؟ أو شارك بأفكارك حول الكيفية التي يجب أن يتم بها تمديد الخلطات ، ولكن بدون بناء الجملة "الموسع"؟

في حالة الاستخدام الخاصة بك ، يعمل ، لكن تجميع المحددات لن يكون له النتيجة المرجوة في جميع الحالات ، لأنه من المحتمل أن ينقل المحددات "في وقت سابق" في المستند لمنع الإعلانات التي كانت تقوم بالكتابة فوق تلك المحددات.
...
أعتقد أننا نسيء استخدام بناء الجملة الموسعة. إذا كانت الصيغة الموسعة كما هي لا تتناسب مع mixins (وهو أمر معقول تمامًا) ، فأنا أقترح أن نجد الصيغة الصحيحة للمزيجات ، بدلاً من توسيع بناء الجملة بطريقة تشوه الاستعارة ، كما يشير bdkjones .

لا ، لم يشر إلى أي شيء ، لقد حثنا على جعل استخدام أقل - كان هذا هو الحد الأدنى. كانت طريقته المقترحة لفعل ذلك مضللة ، لكن النية كانت جيدة. ما لم يكن يفكر فيه هو السلسلة التي أشرت إليها للتو. عند استخدام الامتداد بشكل عام ، يجب أن تأخذ التتالي في الاعتبار. أعتقد أن أي شخص يستخدم تمديد بدلاً من mixin يدرك ذلك. وبالتالي ، فإن هذا هو السبب في أن Less.js يقدم لك خيار إما استخدامه عندما يكون منطقيًا ، أو _لا_ عندما لا يكون كذلك. حقيقة أن أول "C" في CSS يرمز إلى التتالي لا ينفي ميزة دمج الأنماط المكررة عندما لا يكون التسلسل ماديًا. ما الذي افتقده هنا؟

فهل يمكنك توضيح مشاعرك؟ هل أنت ضد هذه الميزة أو بناء الجملة؟ إذا كنت تعارض بناء الجملة ، فالرجاء اقتراح شيء آخر للحفاظ على سير الأمور ، وإلا فلن نعيق تقدم الميزة الواعدة للغة.

هل أنت ضد هذه الميزة أو بناء الجملة؟

أنا مع الميزة ، بالتأكيد. هذا اتجاه واضح. لقد راجعت بناء الجملة مرة أخرى في هذا الموضوع. بعض الأفكار:

أولاً ، هذا محرج بالنسبة لي:

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

الأقواس المزدوجة غريبة فقط. ولكنه اعتماد صادق للنحو الموسع الموجود ، وهو أمر عادل بما فيه الكفاية. لهذا السبب كنت أدافع عن شيء آخر ، ربما شيء آخر غير الامتداد.

ثم هناك هذا الذي اقترحته ، وأعتقد أنه لأسباب مماثلة:

.border-radius(9px):extend;

... الذي كان لدي رد فعل تحسسي تجاهه ، لأنه يبدو مخالفاً لمواصفات الامتداد الحالية. هذا هو المكان الذي بدا لي أنه سوء استخدام.

لكن

أدركت أن هناك بالفعل خيارين هناك. الأول هو أننا نفعل شيئًا مختلفًا للخلطات. لكن الخيار الآخر هو أننا نراجع مواصفات الامتداد الحالية ، لجميع الأشياء ، بما في ذلك الخلطات ، مثل:

#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;
}

لكن .... مع المحدد الكامل ( .some .random .selector ) ، يبدأ في القراءة بشكل خاطئ. يبدو أن .Selector لديه الامتداد عليه. وتختفي كلمة "تمديد" عندما تكون الكلمة المهمة في هذا الإعلان. لم يكن هذا هو الحال عندما تمت كتابته كـ &:extend() (لأنه ظهر في البداية) ، ولكن يبدو أن بناء الجملة هذا ينهار مع mixins.

لذلك ، أقترح أحد هذه الخيارات:

// 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;
}

أعتقد أن المناقشة حول توسيع الخلطات واستعلامات الوسائط قد أبرزت أن نهجنا الأصلي في بناء الجملة إلى :extend ليس بهذه المرونة ، خاصة عندما نريد توسيع المحددات والمزج المتعددة.

أعتقد أنه من المهم الحصول على: التمديد بشكل صحيح. إذا أردنا استخدام "extension" ل mixins ، فأعتقد أنه يتعين علينا مراجعة بناء الجملة الموسعة.

لم أقترح .border-radius(9px):extend; ، فعل DesignByOnyx . اقترحت .border-radius:extend(9px);

لكن كلا من النحو جيد بالنسبة لي. أو يمكننا عمل .border-radius(9px) !extend; أو .border-radius:shamallamadingdongscoobiedoo(9px):extendmyass (jk) ، لا يهمني لأنه لا شيء يتغير مع سلوك mixins أو يمتد على الإطلاق.

لذلك لست متأكدًا من كيفية توصلك إلى الحاجة إلى القيام بكل ذلك ، فمن المحتمل أنك تفرط في تعقيد الأمور على نفسك.

يتعلق طلب الميزة هذا صراحةً بالقدرة على نسخ الخصائص الموروثة لل mixin _ إلى مكان mixin_ ، وسيتبع القواعد التي تم تأسيسها جيدًا بالفعل مع سلوك mixin الحالي ، ولديها الآن أيضًا أسبقية وسلوك مماثل لـ ميزة <strong i="14">@import</strong> (reference) (والتي ، بالمناسبة ، كنت أستخدمها كثيرًا في الممارسة والحب). شيء صغير:

• عند استخدام mixin ، يتم نسخ خصائصه إلى مكان المحدد الذي يستدعي mixin.
• عند استخدام الامتداد ، يتم نسخ المحدد _extending_ إلى مكان الفئة _extended_.
• وبالتالي ، عند تمديد mixin ، يتم نسخ محدد الاتصال إلى مكان mixin.

لست متأكدًا من سبب رغبتك حتى في إعادة صياغة النقاش حول بناء الجملة لتمديده بعد عامين من النقاش ،> 100 منشور ، والكثير من الأبحاث وقد تم بالفعل إثبات أنه أكثر مرونة من @extend .

راجع للشغل ، لست متأكدًا مما تقصده هنا:

مع محدد كامل (. بعض. عشوائي. محدد) ، يبدأ في القراءة بشكل خاطئ. يبدو أن .Selector لديه الامتداد عليه. وتختفي كلمة "تمديد" عندما تكون الكلمة المهمة في هذا الإعلان.

لا أوافق على أنه محير ، لأن هذه هي الطريقة التي يعمل بها الآن. أليس هذا مثل قول "مطورو CSS لا يعرفون كيفية عمل المحددات المجمعة"؟ ماذا عن :hover أو :after ؟ أعتقد أن مطوري CSS يمكنهم معرفة ذلك بشكل جيد ، لأنه يعمل بنفس طريقة عمل pseduos الأخرى.

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

تعجبني المرونة التي يوفرها هذا ، حيث يمكنني (أو كليهما) التقديم على المحدد ، وهو .some .random .selector ، وليس .selector ، أو يمكنني وضعه داخل كتلة المحدد.

أعتقد أن النقاش حول تمديد الخلطات والاستفسارات الإعلامية

لقد أغلقت مشكلة استفسارات الوسائط لأنني أدركت أنه يمكن حلها عن طريق تمديد الخلطات. "كل الطرق تؤدي إلى _____" الخلطات الممتدة. ؛-)

أود أن أقول إن الأقواس داخل أقواس - :extend( .some-mixin() ) - لا تزعجني كثيرًا حقًا ، خاصة وأن :extend( .some-selector ) قد تم إنشاؤه بالفعل وتمت مناقشته بشكل مثير للغثيان. أوافق على أن الأقواس المزدوجة ليست مثالية بأي حال من الأحوال وأنها تبدو غريبة نوعًا ما. لكني أشعر أنه من المهم أن يتم التعامل مع العناصر المختلطة والمحددات بنفس الطريقة من حيث "التمديد" ، بنفس الطريقة التي يتم التعامل بها بنفس الطريقة في "أقل" الكلاسيكية:

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

على هذا النحو ، لا أشعر حقًا بالسوء (أو التقييد) من خلال القيام بذلك:

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

لكني أشعر أنه من المهم أن يتم التعامل مع العناصر المختلطة والمحددات بنفس الطريقة من حيث "التمديد" ، بنفس الطريقة التي يتم التعامل بها بنفس الطريقة في الكلاسيكية الأقل

أنا في نفس الصفحة بخصوص تلك النقطة.

لست متأكدًا من سبب رغبتك حتى في إعادة صياغة النقاش حول بناء الجملة لتمديده بعد عامين من النقاش ،> 100 مشاركة

إنها ليست مسألة الرغبة في ذلك. لا ، لا أريد ذلك. ومع ذلك ، في ذلك الوقت ، قمنا نوعًا ما بخلط الخلطات ليتم التعامل معها لاحقًا. أريد فقط أن أطرح السؤال إذا كنا على يقين من أن بناء الجملة هذا يعمل بالطريقة التي نريدها أن تعمل مع كل شيء. لا حرج في إعادة النظر في السؤال إذا شعرنا أنه لا يعمل أو أنه غير أنيق لبعض الاستخدامات. لقد وجدت أقل من وقت طويل دون تمديد. إن القيام بذلك بشكل صحيح أهم من القيام به بسرعة.

لذا ، نحن رائعون مع هذا؟

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

أقواس داخل أقواس -: extension (.some-mixin ()) - لا يزعجني كثيرًا ، خاصة وأن: extension (.some-selector) تم إنشاؤه بالفعل

نعم صحيح ، ونشير في الواقع إلى أن لدينا بالفعل سابقة لأقواس مزدوجة في Less.js أيضًا ، ومع بناء جملة ممتد موجود. والسابقة التي تم وضعها بالفعل ليست سهلة على العيون مثل ما نقترحه مع الخلطات. حاليًا ، يمكننا القيام بذلك:

.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;
}

سوف تجد حتى أقواس متداخلة في بناء جملة CSS الحالي .

إذن لدينا هنا كلاً من البنية المتداخلة المتشابكة والطبقة الزائفة المتداخلة. وليس لدي مشكلة في ذلك ، فمن الواضح IMO.

لذلك أتفق مع @ DesignByOnyx ، كان هذا اقتراحي الأصلي وبدا مقيتًا للآخرين لسبب ما ، لذلك كنت أحاول إيجاد صيغة أخرى. لكني أستخدم جميعًا فقط بناء جملة mixin القديم المنتظم داخل أقواس الامتداد.

في الواقع ، سيسمح بناء الجملة الأصلي بتمديد فئات أو مزيج مفصولة بفواصل متعددة.

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

إنه يقوم بالمهمة ، وهو ضيق. لا شكاوى هنا.

لذا ، نحن رائعون مع هذا؟

نعم. تماما. هذا هو الحال بالفعل في CSS. لذلك أنا جيد معها.

نعم. تماما. هذا هو الحال بالفعل في CSS. لذلك أنا جيد معها.

لذا يجب أن يمر.

سؤال ، لا أعتقد أننا نوفر حاليًا دعمًا للعديد من المحددات في: توسيع ، لذلك أتساءل عن المكان المناسب للكلمة الرئيسية "الكل" في هذا التنسيق ، ولكن من المحتمل أن يكون ذلك جزءًا من مشكلة منفصلة.

لقد عززت قضيتك ، سيد شلينكرت. كان يجب أن تصبح قانونًا. ؛)

لا أعتقد أن لدينا حاليًا دعمًا لعدة محددات في: extension

لكننا على الرغم من ذلك ؛-) لقد فعلت ذلك على نطاق واسع. فقط فعلت هذا في وقت سابق:

.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%);      
    }
  }
}

لقد عززت قضيتك ، سيد شلينكرت. كان يجب أن تصبح قانونًا. ؛)

بفت ، لول أوه توقفك!

أريد فقط أن أضيف أنني أعتقد أن بناء الجملة هذا:

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

عظيم. لا أجد الأقواس محرجة على الإطلاق.

ولكن بشكل أساسي ، أريد فقط أن تسرعوا يا رفاق حتى أتمكن من القيام بكل الأشياء الرائعة التي أعمل عليها في SASS في معالجي المفضل: D

شكرًا على ملاحظاتك ، mgerring !

+1 في انتظار هذه الميزة. ثابر على العمل الجيد :)

إلى المنشور الأصلي:

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

ربما هذا لم ينجح في وقت النشر؟ ولكن ينتج عنه شيء قريب جدًا مما تريده:

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

@ aaronmw ، نعم ، تأكد من أن المثال الخاص بك يفعل الشيء نفسه ، ولكن النقطة الأساسية في هذا الاقتراح هي القدرة على تمديد mixin المحدد في مكان آخر (على سبيل المثال ، عندما لا يمكنك أو لا ترغب في تعديل mixin نفسه ، على سبيل المثال ، ملف آخر ، مشترك مكتبة الخ)

نعم ، لكل نقطة @ Seven-phase-max ، يمكن القيام بذلك بالطريقة التي تصفها ، لكنها ليست اصطلاحية.

صحيح - آسف ، لقد قرأت المزيد من هذا الموضوع الآن وأرى ما نهدف إليه. فئة "الهيكل العظمي" التي استخدمتها هي مجرد هراء في المخرجات المترجمة لأن الفئة .clearfixed لن تتم الإشارة إليها صراحةً خارج mixin. &: extension (.clearfix ()) يبدو منطقيًا بالنسبة لي الآن ، وهو مثير جدًا. في الوقت الحالي ، سأتعامل مع فصول الهيكل العظمي المتناثرة في CSS.

مناقشة رائعة هنا!

: +1:

إذن متى يمكننا توقع هذه الميزة؟ من المفيد جدًا لمفاهيم مثل OOCSS إنشاء تركيبات مثل "فئة مجردة".

• قرر كيف نتعامل مع التعشيش / النطاق و mixin مقابل الطبقة العادية على سبيل المثال

.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?

• هل نتعامل مع الحجج؟ هل نجمع الخلطات مع نفس الحجج؟
• قم بالتغيير إلى-css-Visitor حتى لا تزيل تعريفات mixin
• احصل على الزائر الممتد لزيارة تعريفات mixin وإنشاء مجموعة قواعد جديدة مع الفصل الجديد

أعتقد أن أصعب ما في الأمر هو في الواقع اتخاذ قرار بشأن كيفية عملها بالضبط.

قرر كيف نتعامل مع التعشيش / النطاق و mixin مقابل الطبقة العادية على سبيل المثال

سأحاول تفسير امتداد mixin بهذه الطريقة:
يجب أن يتصرف .b:extend(.a(1, 2, 3)) {} معادلاً لإنشاء مزيج مجهول غير حدودي (أي محدد بسيط) في نطاق 'b' الذي يستدعي .a(1, 2, 3) بالداخل ثم يمتد بالطريقة المعتادة ، أي هذا:

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

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

يجب أن تكون مساوية لهذا:

.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) {}

باستثناء عدم ظهور #__ anon_a_1_2_3 في الإخراج. أعتقد أن مثل هذا النهج يجب أن يجعله أقل أو أكثر وضوحًا دون اختراع أي قواعد خاصة.

لذلك من خلال تطبيق المفهوم أعلاه على المثال #thing .a نحصل على ما يلي:

.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}

من ناحية أخرى ، تعتبر "الأقواس الاختيارية" شيئًا بسيطًا جدًا من وجهة نظر عملية ، لذلك قد يكون من المناسب أيضًا جعلها أكثر صرامة وتتطلب أقواسًا لمزيج حدودي داخل extend (لا يوجد ضغط على extend ليرث بناء جملة مكالمات mixin لأنه لن يكون متوافقًا تمامًا على أي حال).

هل نجمع الخلطات مع نفس الحجج؟

من الناحية المثالية نعم ، وإلا فإنه سيجعل كل شيء عديم الفائدة ، على سبيل المثال:

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

يجب أن تخلق:

.b, .c {color: green}

حسنًا ، يبدو أن الدمج سيكون أصعب شيء في التنفيذ.

هناك مشكلة أخرى وهي النطاق ، كما ظهر مؤخرًا في رقم 1730 ، تستخدم mixins مسار النطاق "النسبي" وتوسع الاستخدامات "المطلقة" ، لذلك نحصل على نوع من التعارض عند الجمع بين كليهما:

.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()) {} // -> ???
}

وسيكون الأمر محيرًا أكثر إذا أعدنا كتابة هذا المثال باستخدام الخلطات البارامترية.

أود أن أقدم سنتي لأقول إن هذا قد يكون وقتًا مناسبًا للتراجع وقول "كيف ينبغي استخدام مزيج الخلطات " - وأعتقد أن

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

لا أعتقد أننا يجب أن نركز على المواقف التي قد يرغب المستخدم فيها في القيام بما يلي:

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

ليس هذا فقط هو السيناريو الهامشي IMO ، ولكن يجب على المستخدم كتابة أنماطه مثل هذا على أي حال:

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

إن حالة الاستخدام البالغة 99.8٪ لتوسيع الخلطات هي السماح للمطورين بالحصول على مكتبات LESS الضخمة الخاصة بهم مليئة بالأنماط التي جمعوها على مر السنين. ستكون هذه المكتبة الضخمة مليئة بأشياء مثل:

.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 ...]

ويمكنهم التركيز على أساليب الكتابة:

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

يمكنهم حتى القيام بذلك ، إذا أرادوا ولن يكون أي من الأنماط "المشروطة" موجودًا في الإخراج النهائي لأنه لا يتم استخدامها في هذا المشروع:

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

نعم ، أشعر أن DesignByOnyx لديها نقطة. لا أعتقد أن هناك أي خطأ في اكتشاف أشياء أكثر تعقيدًا لاحقًا. في الواقع ، أعتقد أنه سيكون من الأفضل في الوقت الحالي تنفيذ الخلطات الموسعة _ فقط غير البارامترية_ أولاً. سيغطي ذلك على الأرجح 80-90 ٪ من جميع حالات الاستخدام (مما يسمح ببنية أكثر توجيهًا للكائنات إلى أوراق الأنماط ، وما إلى ذلك). كل شيء آخر يمكن أن ينتظر رقعة أو اثنتين ، المنظمة البحرية الدولية.

DesignByOnyx و calvinjuarez لا يمكننا اكتشاف هذا لاحقًا .. يجب ترميزه بطريقة أو بأخرى. إذا قفزنا إلى حل ثم قررنا تغييره لاحقًا ، فإننا نقدم تغييرات عاجلة ، وهذا ليس جيدًا.

إذا تمكنا من وضع نهج لا يدعم السيناريوهات الهامشية ، فأنا أكثر من سعيد ، وهذا نوع من ما فعلناه مع الدعم الموسع الرئيسي (يمكن توسيعه بمزيد من الكلمات الرئيسية ، إذا لزم الأمر) ، لكننا نحتاج إلى خطة لما يتم دعمه وكيف.

@ Seven-phase-max في الوريد أعلاه ، سأكون سعيدًا بتجاهل الخلطات البارامترية في الوقت الحالي.

حسنًا ، يبدو أن الدمج سيكون أصعب شيء في التنفيذ.

• لكنها مندمجة؟ سأستخدم نفس النهج مثل الامتدادات الحالية ، على سبيل المثال ، يجد تطابقًا ويلحق به .. لذا فهو لا يندمج بقدر ما يتم وضع كليهما في مكان ثالث ، وهو mixin ، والذي يتم إنتاجه بعد ذلك باعتباره عنصرًا خاصًا الحال في genCSS

أعتقد أيضًا أن المثال الثاني لـ @ Seven-

lukeapage : +1: صحيح ، يمكنني حفر ذلك. دعوة جيدة.

في الواقع ، أعتقد أن @ Seven-stage-max قد فهمت الأمر بشكل صحيح. إذن: +1: هناك أيضًا.

lukeapage - لم أكن أحاول أن :extend يعمل على النحو التالي:

.block { color: green; }

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

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

لا أرى أي سبب يجعل الكود التالي يعمل بشكل مختلف عن ما ورد أعلاه - الميزة هي عدم وجود فئة .block في المخرجات النهائية:

.block() { color: green; }

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

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

راجع للشغل ، هناك انجراف طفيف في اصطلاحات التسمية لدينا :) على سبيل المثال بالنسبة لي ، تعني عبارة "الخلطات البارامترية" أي مزيج معرّف بأقواس ، بما في ذلك تلك التي تحتوي على معلمات 0 (على سبيل المثال ، .mixin() {} هو واحد "حدودي"). و mixin "non-parametric" هو مجرد محدد بسيط (مثل .mixin {} ). أعتقد حتى الآن أن هذا الانجراف لم يتسبب في أي سوء فهم (على سبيل المثال ، في معظم الأمثلة أعلاه ، كان واضحًا من السياق ما إذا كان قد تمت الإشارة إلى .mixin() {} على أنه مزيج "غير حدودي") ، ولكن ...
لا تفوت أنه في المستندات يسمى المحدد البسيط "mixin" أيضًا (بمجرد خلطه) وهو أيضًا مزيج "غير حدودي" حسب التصميم. لذا فإن الإشارة إلى .mixin() {} فيما يتعلق بـ "non-parametric" فقط قد يكون غامضًا تمامًا (من الناحية الفنية يكون الاختلاف في وجود أو عدم وجود أقواس تعريف وليس في عدد الوسائط).
حسنًا ، كان هذا هو بوو بوو المعتاد. :)

تضمين التغريدة

سأكون سعيدًا بتجاهل الخلطات البارامترية في الوقت الحالي.

أي لا يدعم التمديد للخلطات ذات المعلمات غير الصفرية؟ أنا موافق على ذلك. كنت أحاول فقط تقدير كيفية تنفيذ ذلك (بطريقة موحدة دون تحديد مزج المعلمات الصفرية وغير الصفرية ، حتى لا يكون الأمر بمثابة توقف للعرض عندما / إذا قفز الأخير في النهاية).

لكنها مندمجة؟ سأستخدم نفس النهج مثل الامتدادات الحالية ، على سبيل المثال ، يجد تطابقًا ويلحق به ..

حسنًا ، أعتقد أنني كنت أفكر أكثر في الصعوبات المحتملة في دمج امتدادات الخلطات مع الحجج الفعلية: على سبيل المثال:

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

من ناحية أخرى ، أظن أن هناك مفاجآت خفية مع الخلطات الصفرية أيضًا ، على سبيل المثال:

.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 :)

حسنًا ، ربما يكون هذا عميقًا جدًا (وأيضًا أقل من الاهتمام به في الوقت الحالي).

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

مع التفكير في أنه "نظرًا لأن ، في هذا المثال ، .d() هو حدودي ، فلا يجب إنشاء كتلتين .f "؟

نعم ، يمكنني رؤية وجهة نظرك ، نظرًا لأن المزج سيؤدي إلى:

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

IMHO إذا كان من المنطقي القيام بذلك في خطوات ، فربما أوضح ذلك فقط ، لكنني لن أقوم بتنفيذ شيء ما لتجنب الشكوى في حد ذاتها. بالطبع ، هذا فقط 2c. وإذا تم تنفيذه بالسلوك الذي وصفته ، يمكنك - في وقت إضافة الميزة - أيضًا إنشاء طلب ميزة من أجل "دمج كتل CSS من المحددات الموسعة" ، فقط لتفادي الشكاوى ...؟

لكنني لن أنفذ شيئًا لتجنب الشكوى في حد ذاتها.

أنا موافق تمامًا. أحاول فقط أن أتنبأ بأي مفاجآت يمكن أن تصبح واحدة من تلك المفاجآت التي "فات الأوان لتغييرها".

: +1: نعم ، أحب كيف تفكر!

أنا أحب أن هذه المناقشة لا تزال مستمرة. اسمحوا لي أن أعود إلى بعض نقاط هذه المناقشة. أولاً ، فيما يتعلق بالاستخدام العام ، كان هذا متساويًا.

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

باستثناء أن .mixin {} يحصل على الإخراج كفئة. أعلم في المحلل اللغوي أنهم ربما يعاملون بشكل مختلف ، لكن في الاستخدام ، يتخلصون من أزواج الممتلكات / القيمة.

المعنى:

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

بسبب هذا التاريخ الأقل في بناء الجملة ، فمن المنطقي أنني سأكون قادرًا على القيام بذلك:

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

بالنسبة لي ، هذا غير مثير للجدل ، كما تحدثنا عنه كثيرًا: التمديد كبديل للإسقاط للعديد من حالات استخدام mixin الأصلي.

بالنسبة للشخص العادي ، من المحتمل أن يكون هذا متطابقًا بشكل حدسي ، لأنه يمكن الإشارة إلى .mixin1 تاريخيًا بالطريقة التالية ، سواء تمت كتابته بأقواس أم لا:

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

لذلك ، أتوقع هذا:

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

...لإخراج...

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

إذا تم تعريف mixin مرتين ، فسيتم استبداله مرتين عند تمديده ، تمامًا مثل أخته ، محدد الفئة.

.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;
}

هذا هو الأساس الذي يعمل به التمديد الآن إذا كنت تريد إزالة الأقواس الموجودة في تعريفات mixin ، باستثناء ، بالطبع ، أن اسم mixin سيظهر في الإخراج ، لذلك سيكون من المنطقي اتباع سلوك الامتداد الحالي.

مع المعلمات (حالة الاستخدام 90٪ الخاصة بي) ، نفس الشيء ، باستثناء أنها متباينة عن طريق الإدخال:

.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;
}

بالنسبة لي ، السبب في تمديد mixins هو التجميع على المعلمات ، مما يؤدي إلى مكتبات mixin أكثر قوة يمكنها إنتاج مخرجات موجزة للغاية. لا يعد استخدامها في عمليات المزج التي لا تحتوي على معلمات أمرًا مهمًا ، حيث يمكنني فقط استخدام الميزات الأقل الموجودة اليوم للحصول على النتيجة المرجوة.

شكرا للجميع لمواصلة دفع هذا إلى الأمام. أعتقد أنه يمكن أن يكون إضافة قوية جدًا.

: +1 شكرًا @ Matthew-dean على التفاصيل الشاملة - أتفق مع كل ما قمت بتغطيته. هل يمكنك إبداء آرائك حول هذا السيناريو ، وهو أحد مواضيع النقاش الأخير:

.mixin() { color: red; }

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

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

الطريقة التي يعمل بها LESS حاليًا ، يتم تمديد عمليات المزج في النطاق العالمي فقط - مما يعني أن الأنماط الحمراء ستمتد. أنا شخصياً موافق على هذا السلوك ، وبينما من المحتمل أن يكتب شخص ما الكود أعلاه ويتوقع أن تسود الأنماط الزرقاء ، أعتقد أن السلوك "العام" للامتدادات هو سطر واحد في الوثائق.

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

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

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

أعتقد أن السلوك "العالمي" للامتدادات هو سطر واحد في التوثيق.

أتفق تماما. أعتقد أنها فكرة رهيبة لإدخال منطقة رمادية هنا.

بالنسبة لي ، الاتساق هو المهم. إذا كان السلوك الحالي لا يوسع المحددات في النطاق المحلي ، ولا ينبغي أن يكون مع mixins. إذا قمنا لاحقًا بتوسيع المحددات في المستوى المحلي ، فيجب أن تكون الخلطات أيضًا. يجب أن يكون الناس قادرين على الوثوق بنمط: توسيع هذا على مستوى المكتبة.

(على الرغم من أنه كان بإمكاني أن أقول بإيجاز أكثر: "+1 لتعليقjonschlinkert ". ؛-)

في هذه المرحلة ، هل يمكن لأي شخص تقديم حالة استخدام من شأنها أن تجعل هذه الميزة مربكة؟ يرجى البدء بهذه النظرة العامة الشاملة من @ matthew-dean والردود بعد ذلك ومحاولة تقديم وضع واقعي لم تتم تغطيته.

اجازة سعيدة. عيد ميلاد مجيد. فيليس فيستاس!

نظرة عامة لطيفة حقا. أتفق مع @ Matthew-dean وكل تعليق لاحق. : +1:

أتفق أيضًا مع @ Matthew-dean. يبدو وكأنه زميل منتفخ وأود أن أصافحه.

(-مجهول)

@ كلمة ماثيو دين. : +1:

يمكننا أن نجعل كود نظام شبكة Bootstrap أكثر نظافة بهذه الميزة!

: +1: موافقcvrebert! سيكون جميلا!

مجرد إعادة النظر. أعتقد أن لدينا شبه إجماع ونحتاج فقط إلى التنفيذ ، أليس كذلك؟

أحاول العثور على مزيد من المعلومات حول هذا الأمر ولكنه يشبه المتاهة التي تقرأ كل شيء. هل تم تنفيذ هذا من قبل؟ إذا كان الأمر كذلك ، يمكن لشخص ما أن يوجهني إلى المنطقة المناسبة في المستندات.

@ josh18 لا ، عندما لا يزال طلب الميزة مفتوحًا ، فهذا يعني عادةً أنه لم يتم تنفيذه.

حسنًا ، شكرًا ، اعتقدت أنني سأفحص مرة أخرى فقط في حالة فقد شيء ما.

أخطط في وقت ما لتلخيص الميزات المفتوحة / التي سيتم تنفيذها في Wiki ، لكن لم يكن لدي الوقت بعد.

أخطط في وقت ما لتلخيص الميزات المفتوحة / التي سيتم تنفيذها في Wiki ، لكن لم يكن لدي الوقت بعد.

@ ماثيو دين +1

اهلا ياجماعة! بقدر ما أفهم ، ستكون هذه الميزة مشابهة إلى حد ما للعناصر النائبة لـ SASS. أردت فقط معرفة متى سيتم تنفيذ هذا؟

أهلا،
أجد صعوبة في التنبؤ بوقتي والمساهمين الآخرين فقط
ينفذون الأشياء التي يهتمون بها ، لذا لست متأكدًا. كل ما يمكنني قوله هو
التي نعتبرها ذات أولوية عالية ، إنها الشيء الكبير التالي في قائمتي.

شكرا لاجابتك. نتطلع إلى رؤية هذا التنفيذ والعمل. :)

+1 لهذه الميزة. إنه مفيد للغاية في تقليل حجم CSS.

+1 لهذه الميزة.

+1 لهذه الميزة.

1+ مشاهدة باهتمام ، شكرًا!

: +1:

لقد مر عامان منذ إنشاء هذه المشكلة. علامة أولوية عالية منذ نوفمبر 2014. Milestone هو 1.6.0 أو 2.0.0. رائعة. أقل من 2.5 الآن.

تضمين التغريدة

تقصد أنك مستعد لإجراء العلاقات العامة؟

@ سبع مراحل كحد أقصى هذا ما اعتقدته إلى حد كبير. مثل هذا العرض من الاستحقاق. ؛)

@ سبع مراحل ماكس لول لا أنا فقط الواجهة الأمامية / المصمم.
Celc يبدو حقا سيئا 😅

لقد مر عامان منذ إنشاء هذه المشكلة.

أجل ، ما الذي أدفع لكم من أجله ، على أي حال؟ ؛-)

للأسف لا أستطيع المساعدة في المشاركة ، لكنني أيد بشدة هذا الطلب!

هذه وظيفة مهمة للغاية لبناء أطر عمل معقدة وفعالة

3 سنوات والعدد في ازدياد. لحسن الحظ ، Sass v4 قادم (مع وظائف مسبوقة sass-* ) ويمكنني التخلص من Less.

stevenvachon نحن لا نحمل ضغينة ضد ساس. بالطبع هم منافسون بمعنى ما ، لكن المشاريع لها فلسفة مختلفة ومحاولة إيذاءنا من خلال استحضارها أمر لا معنى له.

بالطبع ، طلبات السحب مرحب بها من أي شخص. سنقوم بكل سرور بدمج طلب السحب الوظيفي مع هذه الميزة.

أنا لا أحاول إيذاء أي شخص ، في الواقع ربما أحاول منع ذلك. أعتقد أنه من الأفضل التعبير عن ما قد يشعر به المرء وعن الاتجاهات الجديدة التي قد يتخذها نتيجة لذلك. أعتقد أنه من الأفضل أن تعرف عاجلاً وليس آجلاً ؛ قبل أن يغادر الجميع. على سبيل المثال ، لن يستخدم Bootstrap v4 Less.js وأنا متأكد من أن ذلك سيؤثر بشكل كبير على قاعدة المستخدمين لديك. يمكنك تجاهل مثل هذه السياسة كما تريد بالطبع.

stevenvachon لماذا : ميزة التوسيع المضمنة بالفعل في LESS وتفي بجميع احتياجاتي. لا أعرف حتى لماذا لا تزال هذه المشكلة مفتوحة.

هيك ، أنا مطور سكك حديدية وأستخدم gulp + LESS عندما لا يكون مشروعًا روبي.

خارج الموضوع؟ لم يتم تنفيذ هذه الميزة في 3 سنوات وستكون مفيدة للغاية.

أفضل ما إذا كان Sass مكتوبًا بلغة JS ، لكنه ليس كذلك ، وهذا ليس هو الأهم. ميزاته. يسمح لنا Sass بتوسيع العناصر النائبة ولكن Less لا يسمح لنا بتوسيع عمليات الخلط.

يا صاح ، إنها ليست بعيدة عن الأنظار على الإطلاق ، ولكنها ميزة منتظرة للغاية! (على الرغم من أنني أفضل أقل على أي حال ، لأسباب مختلفة)

انها مجرد تسول لتكون مصنوعة.

ملاحظة: في حالتي ، أنا مصمم في الواقع مع بعض المعرفة فقط بـ js ، ومعظمها من الأشياء ذات الصلة بـ dom ، حقًا بعيد كل البعد عن المطور الذي يمكنه المساهمة في أقل. js codebase .. وهي قصة حزينة على أي حال)

مجرد مؤيد مهتم للغاية بالمشروع)

إعلان الخدمة العامة

في أي وقت ، يمكنك إرسال طلب سحب ، أو العمل مع مطور للحصول على واحد ، ومن المحتمل جدًا أن يتم دمج هذه الميزة. تحتاج مكتبة Less.js إلى المزيد من المساهمات المنتظمة من الأفراد مثل الأشخاص الموجودين في هذا الموضوع . إنها ليست مسؤولية أي شخص. إنه يعتمد كليًا على فرد واحد يرى هذا الموضوع ، أو يحتاج إلى هذه الميزة ، ويأخذ الوقت الكافي لتحقيق ذلك.

إذا كان ردك هو أنك لست مطورًا ، فهناك العديد من الطرق الأخرى التي يمكنك من خلالها دعم هذا المشروع في أدوار غير تطويرية ، سواء كان ذلك من خلال توفير الوثائق اللازمة للميزات الجديدة ، أو دعم التصميم على موقع الويب ، أو إجراء الاختبارات ، أو تقديم الملاحظات. حول المشكلات ، وإدارة المشروع ، والإجابة على الأسئلة على Stack Overflow ، وكتابة منشورات المدونة ، والتغريد حول Less ، والمساهمة في CSS ومجتمعات الويب ، وكتابة مكتبات أقل.

يتم تنفيذ العديد من هذه المهام بواسطة أفراد من المطورين ، لذا فإن الوقت الذي يمكن أن يساهموا فيه في التطوير يتم إنفاقه على هذه المهام الأخرى.

إذا كنت _ مطورًا ، وكان ردك ، "ليس لدي الوقت" ، فهذا هو السبب الدقيق وراء بقاء هذه المشكلة مفتوحة. الأمر متروك لك بنسبة 100٪ إذا تم إكمال الميزة ، لذا فإن السؤال عن سبب عدم إكمالها بواسطة "شخص ما" ليس مفيدًا. _أنت ذلك الشخص. _ سيحدث ، أنا أضمن _ أنه سيحدث ، إذا وعندما تشارك في هذا المشروع. يمكنك الاشتراك في واحدة من أكثر الأدوات مفتوحة المصدر شيوعًا على الويب. يمكنك إحداث فرق في حياة ... الآلاف؟ مئات الآلاف؟ ملايين؟ وكميزة جانبية ، يمكنك التأكد من أن الميزات المفضلة لديك تحدث عاجلاً وليس آجلاً.

إذا كنت تريد أن تحدث هذه الميزة أو أي ميزة أخرى ، فقم بتحقيقها . نحن نحب أن نكون معك. نحن نتمنى العمل معك! القليل يمكن أن يستمر في التحسن والأفضل كلما كبر هذا المجتمع!

اسمع ، أنا أقدر أنه في بعض الأحيان ليس لدى الناس حقًا وقت للمساهمة ومع ذلك لا يزالون يرغبون حقًا في حدوث ميزة معينة. هذا جيد. أود فقط أن أقول إنه إذا كنت في هذا السيناريو ، فأنت تهدف إلى التعاطف والامتنان للأشخاص الذين يتبرعون بوقتهم (وفي بعض الأحيان بالمال) لمساعدتك ، وأنا متأكد من أن الأشخاص الآخرين في المجتمع الأقل سيبذلون قصارى جهدهم من أجل يواصلون القيام بذلك ، لأنهم قادرون.

بإخلاص،
ماثيو دين ، عضو فريق Less.js الأساسي

أنا أدعم بالفعل مشاريعي الخاصة وأستمع إلى طلبات الميزات الخاصة بهم. أنا بصراحة لا أملك الوقت للبحث في جوهر Less.js.

بالنسبة لأولئك الذين يأتون إلى هنا للحصول على دعم sass placeholder (أو "فئة صامتة") ، اقرأ هذا التعليق . لن يأخذك إلى هناك (بسبب # 1851 ووجود مثل هذه الفئات ليست في ملف "مرجعي") ، لكنه أفضل من لا شيء.