Less.js: كود CSS الشرطي

انتقل إلى http://www.lesscss.org/ وابحث عن الحراس.

لتجنب الاضطرار إلى استخدام mixins ، ينظر في طلب الميزة للسماح للحراس على أي css.

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

.button-maker (<strong i="8">@style</strong>: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(<strong i="9">@style</strong> == 'light'){
        /* adds light styling */
    }

    if(<strong i="10">@style</strong> == 'dark'){
        /* adds dark styling */
    }
}

أود أن أضيف +1 كبيرة لهذه الميزة التي أفتقدها حقًا. يعد الاحتفاظ بالحراس بقاعدة بيانات كبيرة كابوسًا حقًا. هذا من شأنه أن يجعل الأمور أسهل كثيرًا ...

يمكننا حتى إضافة بيان التبديل ..

lukeapage ، هل يمكنك إعادة فتح هذه المشكلة من فضلك. أعتقد أننا يجب أن نناقش هذه القضية / الميزة

LESS ليست لغة برمجة. بناء الجملة / النمط يشبه CSS.

يُقصد بـ LESS أن يكون تعريفًا ، مما يعني أنه لا ينبغي أن يكون المواقف المعقدة قادرة على المنطق المتفرّع ، والحلقات ، وما إلى ذلك.

pierresforge هل لديك أي أمثلة حيث يكون الحراس غير كافيين؟

وأين لن يتم حلها من خلال القدرة على الحصول على حراس على أي محدد؟

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

الجملة من http://lesscss.org/
"يقوم LESS بتوسيع CSS بسلوك ديناميكي مثل المتغيرات والمزج والعمليات والوظائف."

نعم LESS ليست لغة برمجة ، لكنها لا تزال تحتوي على ميزات مثل المتغيرات والوظائف والعمليات.
ما هو مفقود هو المنطق الشرطي.

أعتقد أن CSS Media Query ليس سوى المنطق الشرطي.

<strong i="11">@media</strong> all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

إذا كان من الممكن أن يكون لـ CSS منطق شرطي مثل الحراس. فما هو الفرق. يقوم الحراس فقط بتمديده إلى الخلطات.
يسمح الحراس فقط بالشروط خارج كتلة كود CSS وليس داخل كتلة الكود.
يرجى الاطلاع على https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 على سبيل المثال ، لا يمكن للحراس المساعدة في مثل هذا المطلب ..

حتى لغة HTML لها منطق شرطي ، نعم ولغة ترميزية وليست لغة برمجة.

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

lukeapage شكرا ..

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

كلا ، ليس لدي أي مثال لا يكفي فيه الحراس. ومع ذلك ، هناك الكثير من الأماكن التي لا يكون فيها الحراس أفضل من حيث الصيانة.

مثال:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="7">@coreBackgroundColor</strong>, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="8">@coreBackgroundColor</strong>, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="9">@coreBackgroundColor</strong>, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

هو من وجهة نظري أكثر إيجازًا وتوضيحًا لذاته (غالبًا في الحالات التي لا جدوى فيها من إعادة استخدام الكود ، حيث تعتمد الخوارزمية على الكثير من العوامل) من:

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(<strong i="13">@coreBackgroundColor</strong>, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

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

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

محاميSoviut Devil - بشكل أقل ، يمكنك في الواقع وضع استعلامك عن الوسائط داخل محدد ، وهو غالبًا ما يكون مفيدًا جدًا.

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

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

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  <strong i="9">@when</strong> (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="10">@coreBackgroundColor</strong>, 20%);
  }
  <strong i="11">@when</strong> (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="12">@coreBackgroundColor</strong>, 15%);
  }
  <strong i="13">@when</strong> (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(<strong i="16">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(<strong i="17">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

أكثر تفصيلاً من ifs ، بناء جملة أقرب إلى LESS الموجود ، ويقيم كل عبارة بشكل مستقل (مثل LESS / CSS محدد).

بدلاً من ذلك (أو بالإضافة إلى) ، بالمثل ، إرفاق تقييم mixin بنقطة التقييم:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(<strong i="22">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(<strong i="23">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(<strong i="24">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

يمكن القول ، أن حراس مستوى البيان ليسوا أكثر / أقل تعقيدًا أو منطقًا مختلفًا عن حراس مستوى mixin IMO. من المحتمل أن تكون الأمثلة 2 و 3 أقل توسعية في اللغة. فقط ظننت أنني سألقي ذلك هناك للتفكير / المناقشة.

أعتقد أنه لم يكن لدى أي شخص الكثير ليقوله بشأن اقتراح حرس التصريح الذي قدمته. ؛-)

في الحقيقة ، لا ، ليس هناك الكثير ليقوله. سيكون هذا شيئًا رائعًا ، IMO :)

نعم ، إذا كانوا بالفعل على mixins ، ويمكن أن تكون استعلامات الوسائط عناصر داخلية ، فيبدو أن المنطق لتوسيعها معقول. من الغريب ما يعتقدهlukeapage و @ jonschlinkert والآخرون.

matthewdl : +1:

أعتقد أنني دعمتهم بالفعل في القضية التي تمت مناقشتها في .... :)

lukeapage هل تتحدث عن المشكلة رقم 748؟ إذا كان الأمر كذلك ، فقد أضفت القليل إلى بناء الجملة. ؛-)

أرغب في التعبير عن رغبتي في الحصول على شكل من أشكال if أو @when .

لا أتفق مع الرأي القائل بأن الحراس أفضل عالميًا ويجعلون رمز LESS أقل تعقيدًا من استخدام الشروط. أجد مواقف عملية حيث يجعل الحراس في الواقع ملفاتي الأقل قبيحًا وأصعب في القراءة ولكن if / @when سيكون في الواقع قابلاً للقراءة بشكل استثنائي. الحراس و if / @when عبارة عن أدوات بطبيعتها ، يمكن استخدام كل منهما لجعل الأشياء جميلة أو قبيحة وتكون مناسبة بشكل أفضل للمواقف المختلفة. الجحيم ، يمكنني إنشاء ملف ~ 300b .less الذي يستخدم فقط ميزة توسيع المحدد الأساسية LESS لاستهلاك أكثر من 1 جيجابايت من ذاكرة الوصول العشوائي وترك وحدة المعالجة المركزية تتخبط لدقائق.

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

كان قراري هو أخذ صفحة من كيفية تعامل ميدياويكي مع RTL ، من خلال تقديم ورقتي أنماط من واحدة. يقوم ميدياويكي بذلك عن طريق كتابة أوراق أنماط بتنسيق LTR ثم قلب ورقة الأنماط لإنشاء ورقة أنماط ثانية من اليمين إلى اليسار. ليست هناك حاجة لمحاولة تجاوز كل شيء محدد لـ LTR للتعامل مع RTL. وبالمثل قررت أن أكتب الأنماط الأساسية الخاصة بي في main.less (وربما الملفات المشار إليها منه لفصل الأنماط) ، لن يتم تجميع هذا الملف مباشرة. بدلاً من ذلك ، سيكون لدي صفحتان من الأنماط وهما desktop.less و mobile.less ، كلاهما سيضع أشياء مثل <strong i="14">@mobile</strong>: true/false; ، <strong i="16">@desktop</strong>: true/false; ، وأيضًا تجاوز بعض المتغيرات الأقل مثل أحجام الأشياء. بهذه الطريقة ، انتهى بي main.less إلى كل من desktop.css و mobile.css ، ويمكنني التعامل مع استعلام / اختبار الوسائط لتحديد أيهما سيتم تحميله في مكان آخر (إذا أردت حقًا أن أتمكن بالفعل من تحديد أيهما سيتم تحميله حتى على جهاز لا يدعم حتى استعلامات الوسائط).

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

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  .dummy() when (<strong i="21">@desktop</strong> = true) {
    .accordion-styles();
  }
  .dummy();
}

في هذه الحالة ، سيكون من المفهوم كثيرًا استخدام شيء مثل @when .

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  <strong i="26">@when</strong> (<strong i="27">@desktop</strong> = true) {
    .accordion-styles();
  }
}

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

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

dantman اعتبارًا من 1.5.0 والحراس على أنماط css المرتبطة يمكنك القيام بذلك

.navigation {
  & when (<strong i="7">@desktop</strong> = true) {
    color:red;
  }
}

وهو السكر لمثالك.

الجانب السلبي الوحيد هو أنه يعتقد في الوقت الحالي أنه محدد جديد لذلك لا يدمجه مع المحدد السابق. ومع ذلك ، أعتقد أن هذا من غير المحتمل أن يسبب لك مشكلات وسيكون شيئًا سأقوم بإصلاحه / سنقوم بإصلاحه في الإصدارات المستقبلية.

حسنًا ، شكرًا ، هل يمكننا توثيق ذلك كميزة؟

لأكون صريحًا ، لست متأكدًا من أنه مفهوم جدًا مقارنة بـ @when ، لست متأكدًا من أنني إذا رأيت سابقًا & when(...) في ملف .less فعل في لمحة. @when كسكر & when() قد يكون رائعًا.

أتفق مع @ matthew-dean لإضافة هذا النوع من الهياكل الشرطية من المحتمل أن يجعل صيانة واختبار الملفات الأساسية LESS أكثر صعوبة. ويصعب تصحيح ملفات .less وهكذا دواليك.

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

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

على سبيل المثال ، لئلا نقول إن لدي ملف باسم "myfile.less.php" يحتوي على كود مجنون به رموز شرطية ومفاتيح ومصفوفات وجميع الأشياء الرائعة التي يمكنك رؤيتها على PHP ثم من هذا الملف ".less.php" ، انسخ ملفًا آخر يسمى " myfile.less " الذي يحتوي على الكود LESS النهائي ، وبهذه الطريقة يمكنني الاستعلام عن جميع متغيرات الخوادم باستخدام PHP ، وتحديد ما الذي سيشملهimports أو يستبعده ، ولم تعد هناك حاجة لتمرير كمية كبيرة من المتغيرات السخيفة إلى مترجم LESS ولست بحاجة إلى كتابة حراس سخيفة يصعب قراءتها لتقليد هياكل IF أو Switch.

يمكن أن يكون سير العمل الأساسي مثل هذا

1- تحقق مما إذا كانت ذاكرة التخزين المؤقت منتهية الصلاحية
1- استدعاء سكريبت لإيجاد ومعالجة جميع الملفات ".less.php" الملفات
2- استدعاء سكريبت لتجميع كافة الملفات ".less"
3- تحديث ذاكرة التخزين المؤقت

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

dantman هناك أشياء قليلة غير موثقة ونعم ، نحتاج إلى توثيق ذلك. هناك جهد جاري في less-docs لتوسيع التوثيق وتحسين موقع الويب كثيرًا. سأضيف مشكلة هناك.

lukeapage ، نعم لقد لاحظت ذلك مؤخرًا. انتقلت عبر سجل التغيير ولاحظت أشياء مثل التدرج اللوني svg ودمج الخصائص مع +.

بالمعنى الدقيق للكلمة ، تم توثيق & when ... بالفعل لأنه مجرد مزيج بسيط من ميزتين موثقتين & و CSS Guards . لكن المثال المخصص لن يضر بالطبع.

@ Seven-stage-max ، لم أكن على علم بهذه الوثائق. من مظهرها ، هذه مجموعة جديدة غير مكتملة من التوثيق لاستبدال الموقع القديم ، من خلال "سيتم نقل هذا إلى مستودعات lesscss.org قريبًا! نوصيك بتجنب الارتباط بهذا الموقع حتى يصبح كل شيء حيًا." تعليق. من الجيد معرفة أن شيئًا كهذا قيد الإعداد.

كنت أشير إلى الوثائق الحالية على lesscss.org والتي كانت المستندات الوحيدة التي كنت على دراية بها ، وحاليًا المستندات فقط كميزة mixin ، ولا توحي بأنها متاحة في أي مكان آخر.

الحراس ليسوا جيدين مثل هذا. :(

هذه ميزة مطلوبة وهي موجودة أيضًا في scass.

+1 لهذا

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

بعض مقاومة @when في المناقشة الأصلية هي القاعدة الإضافية. ومع ذلك ، بالتفكير في الأمر الآن ، لن تكون هناك حاجة إليه.

باعتبار هاتين الكتلتين متساويتين:

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

ثم يجب أن يقبل المحلل اللغوي هاتين العبارتين على قدم المساواة.

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

إذا لم يكن هناك سبب آخر غير & when فهو أمر محرج بالفعل من الناحية التركيبية. حذف & ليظل يشير إلى انضمام محدد مع المحدد الرئيسي موجود طوال الوقت ، لذا فإن حذف & للإشارة ضمنيًا إلى وجود حارس على المحدد الرئيسي لا يبدو وكأنه قفزة. أيضًا ، يتم قبول وظائف block-root الآن بواسطة المحلل اللغوي لاستخدامها مع المكونات الإضافية ، لذلك لم يعد يبدو غريبًا كما قد يكون في 2013.

لا أرى أي سبب لإعادة فتح هذا. بعد كل شيء لدينا بالفعل # 2072

when (1=1) { color: blue; }

فتح مربع ارتباك كبير فقط من أجل اقتصاد شخصيتين؟

الحراس ليسوا جيدين مثل هذا.

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

لا أرى أي سبب لإعادة فتح هذا. بعد كل شيء لدينا بالفعل when (1=1) { color: blue; }

Errr ... لا لا؟

لكن من المعقول أن نفعل ذلك. يمكننا فقط السماح بذلك والانتهاء من ذلك.

انتظر ، حتى أعثر على طلب الميزة الذي من المفترض أن يرتبط به (عذرًا ، لقد قمت بالنقر فوق إدخال بطريق الخطأ قبل الانتهاء منه)

لذا دمج هذا في # 2072.

@ سبع مراحل كحد أقصى

تسمى هذه المشكلة "السماح بإعادة تعريف المتغير داخل كتل التشغيل الذاتية المحمية" والمناقشة العرضية في أسفل هذه المشكلة احتوت على حالات استخدام مماثلة لتحديد / حالة و vbscript iif ([ifcond] ، [ثم] ، [آخر]) تعمل أكثر من مجرد كونها عارية عندما ، على الرغم من أنها ربما تكون أكثر منطقية للمناقشة. Buuut ... ربما يجب أن يتم طرحه كمسألة جديدة فقط مع سؤال when () مقابل & when () .

مع سؤال متى () ومتى ().

لا يمكنك أن تكون جادًا في هذا ، أليس كذلك؟ بسبب ماذا بالضبط؟ لن يصبح $ # when if (راجع # 2072 لجميع الأسباب) إذا قمت بإزالة & . لذا اتركها كما هي وانتهى منها.

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

لم أقصد الإساءة أو شيء من هذا القبيل.
لي:

لذا اتركها كما هي وانتهى منها.

كان مجرد رد على:

يمكننا فقط السماح بذلك والانتهاء من ذلك.

@ سبع مراحل كحد أقصى حسنًا ، تضيع النغمة في النص. على أي حال ، لم أكن مرتبطًا بشكل رهيب بهذه الفكرة ، وبشكل عام ، فإن اقتراح @when الحالي أفضل / أكثر تنوعًا على أي حال.

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

aukgit استخدم الأداة المناسبة للوظيفة. إذا كان SCSS يناسبك بشكل أفضل ، فمن الأفضل استخدامه. Sass and Less هما مشروعان مختلفان تمامًا.

@ Matthew-dean بعد تعلم أقل لأشهر وكتابة أطنان أقل إذا كان المجتمع "أقل" لا يريد أن يكون أفضل فهو خسارة لكلينا. أعتقد أن هذا هو سبب انتقال bootstrap إلى 'sass' (https://github.com/twbs/bootstrap/tree/v4-dev) من أقل (كان السبب الأولي هو التجميع الأسرع). بينما كان هناك المصدر الأولي في "أقل". الآن يكتبون مصدرهم الأصلي في "sass" ثم يحولون إلى أقل (بينما كان العكس).

شيء آخر :

"الأداة المناسبة للوظيفة المناسبة"

لا ينبغي أن تنطبق هنا

أقل | Scss | مشاريع مماثلة ستايلس. بدأت بواحد كان شائعًا في ذلك الوقت ، يبدو الآن أن المجتمع "الأقل" لا يريد تحسين نفسه.

الفكرة من وراء "الأقل" هي أن تكتب أقل وأن تفعل أكثر. في مكان ما يتم الاختزال ولكن في مكان ما يتطلب المزيد من الكتابة.

أشكركم على تعليقاتكم.

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

على سبيل المثال:

لا توجد طريقة لعمل كود شرطي مُجمَّع بالفعل.

نعم ، "أحتاج إلى أداة لكتابة رمز السباغيتي الخاص بي" - تمامًا مثل هذا . إذا كتبت رمزًا كهذا ، فإن Less بالتأكيد ليس أداتك.

أعتقد أن "less" تفعل شيئًا مختلفًا تمامًا عن sass و stylus. كل الآخرين يفعلون أشياء مماثلة في حين أن "الأقل" تدعي أنها ليست من النوع المماثل. :)

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

أعتقد أن "less" تفعل شيئًا مختلفًا تمامًا عن sass و stylus.

_لماذا يجب أن تفعل الشيء نفسه؟ انظر على سبيل المثال [1] و [2] للعثور على الاختلافات الرئيسية بين التصميمات. لذلك قد لا يعجبك هذا المفهوم ولكن لا أحد يجبرك على استخدام أداة لا تحبها.

فهمت الان. شكرا لك. حقًا ، إنها حقًا أكثر اللغات التي يُساء فهمها على الإطلاق. حتى جافا سكريبت لم يساء فهمه كما يقول دوجلاس كروكفورد.

يرتكب الناس أخطاء في js ولكن هناك الكثير من الوعي. بالنسبة لـ "Less" ، يجب أن يكون في الصفحة الأولى (less.org) الذي يصف ما هو أقل وما هو ليس كذلك.

شكرا لك.

كتب ميكس:

أقل:

.if-value-present(@attribute; <strong i="7">@value</strong>: '') {
    .x (@value) when not (<strong i="8">@value</strong> = '') {
        @{attribute}: @value;
    }

    .x(@value);
}

.if-value-present-multi(@attributes; @values) {
    .iter(@i) when (<strong i="9">@i</strong> > 0) {
        .iter(<strong i="10">@i</strong> - 1);
        // loop

        <strong i="11">@attr</strong>: extract(<strong i="12">@attributes</strong>, @i);
        <strong i="13">@value</strong>: extract(<strong i="14">@values</strong>, @i);

        .if-value-present(<strong i="15">@attr</strong>, @value);
    }

    <strong i="16">@len</strong>: length(@values);
    .iter(@len);
}
.x {
    <strong i="17">@var</strong>: c1,c2, c3;
    <strong i="18">@val</strong>: v1, '', 'wddww';
    .if-value-present-multi(@var;@val);
}
.x{
    .if-value-present(content, 'new val');
}

إخراج CSS:

.x {
  c1: v1;
  c3: 'wddww';
}
.x {
  content: 'new val';
}

إذا كان المجتمع "الأقل" لا يريد أن يكون أفضل فهو خسارة لكلينا

أعتقد أنه من الخطأ افتراض أن "الميزة X التي أريدها غير مدعومة" == "المجتمع الأقل لا يريد أن يكون أفضل". هذا لا يقودنا إلى أي مكان.

هناك العديد من المناقشات حول Github للعمل على تحسين تدفقات التحكم. في الواقع ، لم يتم رفض هذا الموضوع ، بل تم دمجه في # 2072. لقد علقت على موضوع مغلق عمره 3 سنوات. كان لدي بعض الأفكار الأخرى التي اعتقدت أنها قد تجعل الأمر مختلفًا قليلاً عن # 2072 ، لكنني كنت مقتنعًا بشكل أساسي بخلاف ذلك.

الآن يبدو أن الإعجابات لا تحتوي على ميزات أفضل

أقل ليس لديه ميزات _ more_ ، هذا صحيح. هذا حسب التصميم. هذا حتى تتمكن من تعلم أقل في يوم واحد ، وتغطي ميزات Less 99٪ من حالات الاستخدام النموذجية. لدى Sass منحنى تعليمي أكثر حدة. كان لدى Sass الكثير من الميزات لدرجة أنه كان عليهم بناء مترجم منخفض المستوى يعتمد على C فقط ليتمكنوا من الاستمرار في تجميعه. وهو إنجاز عظيم. لكنها ليست وصية عظيمة لشيء ما ، في نهاية المطاف ، هو مجرد إعداد ورقة نمط.

الآن يكتبون مصدرهم الأصلي في "sass" ثم يحولون إلى أقل (بينما كان العكس).

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

في نهاية اليوم ، شكواك حول الأطواق اللازمة لكتابة الشروط _ ليست خاطئة_. الأمثلة المعروضة هنا هي ببساطة غير مناسبة للغة. أقترح عليك قراءة الموضوع في # 2072.

(هذا في الواقع بعيد المنال قليلاً ، لكني أتساءل فقط)

<strong i="7">@var</strong>: c1, c2, c3;
<strong i="8">@val</strong>: v1, '', 'wddww';

وما فائدة هذه المتغيرات بجانب استدعاء .if-value-present-multi ؟
(و _ إذا _ هذه المتغيرات _ هي _ تُستخدم لشيء آخر) ألن يكون من المنطقي استخدام أزواج خاصية / قيمة فقط بدلاً من ذلك ، على سبيل المثال:

<strong i="14">@rules</strong>:
    c1 v1,
    c3 'wddww';
   // no need for c2 since it has no effect

علاوة على ذلك ، ما الغرض من كتابة .x {.if-value-present(content, 'new val')} إذا كنت تحتاج فقط .x {content: 'new val'} ؟ وتكتب .x {.if-value-present(content)} إذا لم تفعل شيئًا؟

(على الرغم من الصدق الذي نظرت فيه إلى [1] - حسنًا ، عدم التعليق على أي شيء باستثناء شيء واحد فقط: (_ فقط لتوفير وقتك_) ضع في اعتبارك التخلص من libs القديمة مثل elements و lesshat - و استخدم autoprefixer بدلاً من ذلك. لا نحتاج إلى مكتبات بادئة البائعين لأي من معالج CSS المسبق لبعض الوقت الآن).

هذه هي الطريقة التي تأتي بها معظم "طلبات الميزات": "مشكلة XY" . (أمثلة جيدة أخرى لفشل مماثل في المجال ذي الصلة: # 1400 و # 1894 ، لا يعني ذلك أن الميزات ستكون عديمة الفائدة تمامًا (ومن ثم يتم الاحتفاظ بكليهما مفتوحين) ، ولكن عندما يبدأ المرء في السؤال عن حالات الاستخدام الفعلي ، فإنه عادةً ما يكشف لقد كان خطأ Y في محاولة حل X).

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

هنا https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements . ما لم أحاول تطبيق نفس المزيج مرارًا وتكرارًا حيث كان بإمكاني تحقيقه مع الظروف بسهولة بالغة.

حصلت عليه الآن .. شكرا لكم جميعا.

aukgit يجب أن تكون قادرًا على طي هذه الخلطات بسهولة.

https://gist.github.com/matthew-dean/e617bc1f71528843ef9fa73d70427bcf

شكرًا لك @ ماثيو دين لأخذ وقتك ومساعدتي. :) أنا ممتن لك.

:)

أعتقد أن "ساس" أفضل من أقل. لديها بالفعل if-else.

كلتا اللغتين لهما مشكلاتهما الخاصة.

إن افتقارهم إلى الواردات الديناميكية - وإحجامهم عن تنفيذها - هو السبب الرئيسي الذي يجعلني أرغب في التبديل من Sass إلى Less. أقل لديه هذه الميزة لسنوات!

ومع ذلك ، فإن الافتقار إلى هياكل التحكم التقليدية (مثل عبارات FOR-loop أو IF-ELSE) والبنية الجديرة بالملل هو ما يمنعني من القيام بهذه الخطوة.

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

jslegers نفس التعليق كما في # 249. أقل له أشكال مختلفة (أكثر وأكثر في الإصدار الأحدث) من القيود الشرطية منذ الإصدار 1.x.

@ سبع مراحل كحد أقصى

أنا على دراية بالخلطات المحروسة كبديل لعبارات IF والخلطات العودية كبديل للحلقات في Less. ولكن هذا كل ما تمكنت من العثور عليه في المستندات حول هياكل التحكم في Less. وباعتباري شخصًا لديه خبرة في البرمجة في العديد من اللغات ، أجد نحويهم محيرًا - ولكي أكون صادقًا - جديرًا بالملل.

إذا كانت هناك هياكل تحكم أخرى غير تلك التي تستحق الذكر ، فلم أتمكن من العثور عليها في المستندات.

على أي حال ، شيء مثل ...

scss a { <strong i="11">@if</strong> $time == morning { color: red; } <strong i="12">@else</strong> if $time == afternoon { color: blue; } <strong i="13">@else</strong> { color: grey; } }

... أو شيء من هذا القبيل ...

scss <strong i="17">@each</strong> $author in $list .photo-#{$author} background: image-url("avatars/#{$author}.png") no-repeat

... أو هذا...

scss <strong i="21">@for</strong> $i from 1 through 8 { $width: percentage(1 / $i) .col-#{$i} { width: $width; } }

... في Sass أكثر قابلية للقراءة وأكثر أناقة بكثير في رأيي من الاضطرار إلى كتابة شيء مشابه باستخدام الخلطات المحروسة أو الخلطات العودية في أقل.

يعد عدم وجود مثل هذه العبارات وصيغة Less بشكل عام أقل قابلية للقراءة (مقارنةً بـ Sass) هما السببان الرئيسيان اللذان أفضل التمسك بـ Sass وأنا متردد حتى في التفكير في Less في أحد مشاريعي.

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

jslegers للحصول على أمثلة - حاول معرفة ما هو متاح بالفعل قبل نشرها.
بالنسبة للباقي (الشعبية وما إلى ذلك) - ليس هناك فائدة من مناقشة شيء بهذه الطريقة المبسطة (Stylus لديه كل هذا وماذا في ذلك؟) ، بالإضافة إلى أنه لم يتم الإعلان عن Less لاستبدال معالجات CSS الأولية الأخرى ولا أن تصبح استنساخًا لها. وأخيرًا ، الخطأ الأكثر شيوعًا هو الاعتقاد بأن شعبية شيء ما هي الهدف الأساسي والوحيد من هذا الشيء المؤلفين.

حاول معرفة ما هو متاح بالفعل قبل نشرها.

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

بالنسبة للباقي (الشعبية وما إلى ذلك) - ليس هناك فائدة من مناقشة شيء ما بهذه الطريقة المبسطة [...] وأخيرًا ، فإن الخطأ الأكثر شيوعًا هو الاعتقاد بأن شعبية شيء ما هي الهدف الأساسي والوحيد من هذا الشيء المؤلفين.

لمعلوماتك ، لم ألمح أبدًا إلى أن الشعبية هي مؤشر قوي على الجودة أو الفائدة. في الواقع ، غالبًا ما يكون العكس.

ومع ذلك ، إذا نظرت إلى سبب انتقال الناس من Less إلى Sass ، فسيكون ذلك واضحًا جدًا ...

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

أنا شخصياً لا أستطيع رؤية أي شيء سوى عبارة "أريد معكرونة PHP الخاصة بي"

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

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

فلماذا لا نبذل جهدًا لإيقاظي وإعطائي مصدرًا أو اثنين يمكن أن يريحني من جهلي؟

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