Less.js: طلب الميزة: البحث عن الخاصية (المعروف أيضًا باسم الخصائص هي متغيرات أيضًا)

ما هي حالة الاستخدام الخاصة بك؟ في less.js الحالي ، يمكنك وضع قيمة foo في متغير وتحقيق شيء مشابه.

هذه:

.test {
  <strong i="7">@foo</strong>: 200;
  foo: @foo;
  bar: <strong i="8">@foo</strong> / 2;
  .child {
    baz: @foo;
  }
}

يجمع إلى:

.test {
  foo: 200;
  bar: 100;
}
.test .child {
  baz: 200;
}

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

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

@gutter-width: 30px;
.row {
  margin-left: -(@gutter-width / 2);
  margin-right: -(@gutter-width / 2);

  .col-half {
    width: 50%;
    float: left;
    padding-left: -$margin-left;
    padding-right: -$margin-right;
  }
}

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

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

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

.alert {
  color: #f00;
  background: lighten($color, 25%);
}

أعتقد أنه ليس _ ضروريًا_ ولكن _من الجيد أن يكون لديك_. يمكن للمتغيرات القيام بالمهمة ولكن مراجع الخصائص المباشرة أكثر قابلية للقراءة.

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

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

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

أرى القلق من تفجير اللغة كثيرًا حتى لا يتم اعتبارها "أنيقة" بعد الآن.

متعلق بالرقم 76 و # 6 - على الرغم من أن هذا النهج أبسط. إنه يوفر على الكود غير المجدي الذي يخصص لمتغير ثم يقرأ منه

قراءة # 76 وجدت بعض أوجه التشابه التي يمكن دمجها ، لنقل إذا كنت background-color: lighten([color], 25%); فستبحث عن شجرة السلف الحالية. ومع ذلك ، إذا كتبت background-color: lighten(#mySpecialSelector[color], 25%); فستستخدم بدلاً من ذلك شجرة الأصل للمحدد.

سيكون ذلك مفيدًا حقًا ويفتح مستوى جديدًا تمامًا من الفرص.

lukeapage ماذا تعتقد أن تأثير الكود سيكون؟ إذا كان من الممكن تلميع الخصائص المحلية (الشجرة الحالية) لتتصرف بشكل مشابه للفارس المحلية ، فيبدو أنها لن تكون كبيرة (لكنك ستعرف بشكل أفضل). يمكن أن يضيف أناقة معينة للغة ، حيث يمكن للناس أن يفعلوا:

.rectangle {
  width: 200px;
  height: ([width]/2);
}

بدلا من:

.rectangle {
  <strong i="10">@width</strong>: 200px;
  width: @width;
  height: (@width/2);
}

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

لعمليات البحث المحلية فقط ، أعتقد أن التكلفة صغيرة. إضافة المحددات قد
يؤدي إلى مزيد من التعقيد في التحليل. لا تستخدم الأعمدة css الأقواس المربعة في
القيم؟

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

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

#mySpecialSelector[color] {
}
// matches:
<div id="mySpecialSelector" color></div>

الأقواس المربعة تطابق عنصرًا له السمة "اللون". يمكن أن نكون أكثر وضوحًا ، بشيء مثل prop ().

.rectangle {
  width: 200px;
  height: (prop(width)/2);
}

ومع ذلك ، أعلم في الماضي أننا حاولنا تجنب الأقواس المتداخلة ، لذا ... ماذا لو قمنا بدمج $ مع تركيبنا المتغير المحرف؟

.rectangle {
  width: 200px;
  height: (${width}/2);
}
.example {
  background-color: lighten(${color}, 25%); 
  background-color: lighten(${color, #mySpecialSelector}, 25%);
}

شئ مثل هذا؟ بهذه الطريقة تكون محددات السمات صالحة:

.parent[id] {
  height: 50%;
  .child {
    height: (${height, .parent[id]} / 2);
  }
}

ماذا تظنون يا جماعة؟

أحب ${color} .

في الواقع ، إذا فكرنا في ${} أو أي بناء جملة على أنه "مرجع شجرة" ، فيمكننا معالجة مشكلات مثل # 1075 بنفس البنية:

.table .row .cell {
    ${.row}.editing  {}  // .table .row.editing .cell {}
}

... لكنني لا أريد الخلط بين الأشياء. مجرد فكرة.

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

لكن إذا كتبت background-color: lighten (#mySpecialSelector [color]، 25٪)؛ سيستخدم بدلاً من ذلك شجرة الأصل للمحدد.

بهذه الطريقة لا يمكن أن يكون لدى #mySpecialSelector أي أسلاف (لأنه إذا كان الأمر كذلك ، فيجب الإشارة إليه بـ *ancestor(s) #mySpecialSelector . أي فقط #mySpecialSelector قد يتطابق مع محدد المستوى الأعلى فقط في العالمية النطاق (و / أو اختياريًا عنصر يحمل هذا الاسم في مكان ما في النطاق الحالي لأعلى). ولكن مرة أخرى ، أعتقد أن الجزء الخاص بمساحات الأسماء من الأفضل مناقشته في # 1848 (من المفترض أن تكون الاختلافات بين المتغيرات والخصائص هناك في بناء الجملة فقط (على سبيل المثال selector[@variable] و selector[property] ) _if_ تم تنفيذ هذا).

راجع للشغل ، أي أفكار بجانب $ و [] ؟

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

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

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

.box:after {
  content: "@{#ns > @content}";
}

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

// property
.box:after {
  content: "${#ns > content}";
}
// or a variable
.box:after {
  content: "${#ns > @content}";
}

لذلك ، ربما يمكننا قتل عصفورين (ربما 3) بحجر واحد وتفكيك المهام مثل هذا:

• الخطوة 1: دعم الخصائص كـ "vars" (مع استثناءات محتملة)
• الخطوة 2: العنوان الثاني لمثالkrnlde ببساطة عن طريق دعم مراجع مساحة الاسم بدلاً من المحددات "المحلية": ${#mySpecialSelector > color}

بالنسبة إلى بدائل $ ، أعتقد أننا يجب أن نقتصر على مفتاح التحول وصف الأرقام. لا يمكننا استخدام ! ، @ ، # ، & ، * ، ~ ، `` , as it either conflicts with CSS or Less. That leaves $ , ٪ , ^ . I suppose there's a few more symbols on the keyboard, but if we're going to add one, $ `سيكون خياري الأول.

ماذا عن § و / و \ ؟

يستخدم \ لأحرف Unicode. يجب أن يكون الباقي على ما يرام. هل يسهل الوصول إلى § على لوحات المفاتيح الإنجليزية؟ ليس لدي واحد للتحقق من أجهزة الصراف الآلي.

هل يسهل الوصول إلى § على لوحات المفاتيح الإنجليزية؟ ليس لدي واحد للتحقق من أجهزة الصراف الآلي.

إيه ، كلا. أي فكرة عما هو أن.

إنها فقرة تسجيل الدخول إلى القانون (الألماني)

آه ، حسنًا ، أعتقد أنني رأيت ذلك بعد ذلك. بغض النظر ، فهي ليست على لوحة المفاتيح.

على ما يرام. كما اكتشفت من خلال العبث ، فإن / ليس فقط مرهقًا ولكنه أيضًا غير قابل للاستخدام نظرًا لأنه عامل القسمة بأقل من ذلك ، لذلك لن يعمل padding-top: /height//line-height; على أي حال. لذا أعتقد أننا نتمسك بـ $ في الوقت الحالي؟ مثل padding-top: $height/$line-height; . يبدو جميل

Doh ، أخشى أنني سأصوت لـ $ أيضًا لأنه يبدو أنه الأكثر نظافة والأقل تعارضًا (على الرغم من أنني بصراحة أكره ذلك (بدون سبب معين) وبسبب ذلك أشعر بالألم في كل مرة يجب أن أكتب شيئًا بلغة PHP :)

@ Seven- ومع ذلك ، فقد أصبحت أكثر واقعية مؤخرًا ، وألوي الرموز الحالية لتعني المزيد من الأشياء (كما كنا نلعب فيما يتعلق بـ @ و & ) لتجنب إضافة رموز جديدة ، أو من أجل تقييد أنفسنا بمجموعة الرموز الخاصة بـ CSS ، قد يكون الأمر عبارة عن ألعاب جمباز غير ضرورية ، وليس بالضرورة الحل الأسهل في الفهم. أعتقد أنه من الأسهل على المستخدم فهم الرموز إذا كان لديهم سلوكيات أكثر تميزًا. ولا تحتوي CSS على سلوكيات معينة نمثلها ، لذلك في بعض الحالات قد يكون من غير الحكمة اختيار / إعادة توظيف رموز CSS. ربما يتعارض هذا مع الكثير مما قلته في الماضي ، لكن كما قلت ، لست متأكدًا من أن مثل هذه الصرامة كانت ضرورية دائمًا.

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

ومع ذلك ، لأن هذا قد يكون أسلوبًا جديدًا للرمز / المرجع ، أعتقد أنه يستحق الحصول على الكثير من المدخلات / الإجماع على ذلك.

أفهم أن القدرة على القيام بذلك:

.rectangle {
  width: 200px;
  height: ${width} / 2;
}

يمكن أن يكون لطيفًا ولكن هذا:

.example {
 color: lighten(${color, #mySpecialSelector}, 25%);
}

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

var el1 = document.createElement('div');
var el2 = document.createElement('div');
el1.className = document.querySelector('mySpecialSelector').id + '25percent';
el1.className = document.querySelector('mySpecialSelector').id + '10percent';

بدلا من:

var CLASS_NAME = 'my-color-class';
var el1 = document.createElement('div');
var el2 = document.createElement('div');
el1.className = CLASS_NAME + '25percent';
el1.className = CLASS_NAME + '10percent';

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

هذه:

.example {
 color: lighten(${color, #mySpecialSelector}, 25%);
}

قراءة وإدارة معقدة عديمة الفائدة.

أنا موافق. لهذا السبب أعتقد أن هذه القطعة ربما تستحق الانتقال إلى مؤشر ترابط مرجع مساحة الاسم (# 1848) ، كما اقترح @ Seven-stage-max ، والإشارة إلى تنسيق مساحة الاسم على أي حال. بالنسبة لهذا الخيط المحدد ، يجب أن يكون الشيء الوحيد على الجدول هو الرجوع إلى قيم الخصائص.

kuus ، @ ماثيو دين وافق على ذلك. قد يكون كثيرا.

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

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

: +1:

لتلخيص الوضع الحالي للمناقشة:

• لقد اتفقنا على استخدام صيغة الاستيفاء $ -sign: ${width} على الرغم من أن $width سيكون أقصر والسابق ليس له مزايا (قد يحتاج إلى مناقشة أخرى أثناء تقدمنا).
• نحن نسمح فقط للخصائص بالبحث عن النطاق الحالي لأعلى. المحددات مثل ما يلي غير مسموح بها : height: ${width, .my-selector} أو height: .my-selector${width} .
• اتفقنا على أن مراجع الخصائص في mixins ستبحث عن شجرة mixin أولاً ثم - إذا لم تنجح - في الشجرة التي يتم وضعها فيها.

ماذا عن "التحميل الكسول" للمتغيرات الأقل؟ ما هو تأثير هذه المعرفة على الخصائص؟

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

في الوقت الحالي ، سأقصر القائمة على: $width - يشير إلى خاصية width تبحث من النطاق الحالي إلى أعلى.

(يحتاج تباعد الأسماء وبناء الجملة ${...} مزيد من المناقشة).

في الوقت الحالي ، سأقصر القائمة على: $ width - يشير إلى خاصية العرض التي تبحث من النطاق الحالي إلى أعلى.

متفق. أنا أؤيد القيام بكلتا الصيغتين ، لذا فمن المنطقي أن نبدأ بالصيغة الأكثر "المحدودة" ، ثم نبدأ بعد ذلك بـ ${} .

بالمناسبة krnlde ، أؤيد الآن الإصدار الذي يحتوي على مساحة اسم _ بدلاً من _ بحث محدد "داخل الشجرة" ، حيث يبدو ذلك أكثر مرونة ، ولكن لنبدأ بخاصية $ وننطلق من هناك.

حتى الان جيدة جدا. كيف يمكننا السير للأمام؟

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

في 5 شباط (فبراير) 2015 ، الساعة 12:20 ظهرًا ، كتب Kai Dorschner [email protected] :

حتى الان جيدة جدا. كيف يمكننا السير للأمام؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

لماذا & خارج الطاولة؟ AFAIK ، لا يستخدم Less لا يستخدم & إلا في المحددات. بالإضافة إلى ذلك ، أعتقد أن من الأفضل أن تكون مرجعًا لـ & .

AFAIK ، لا يستخدم Less & ما عدا في المحددات.

نعم الآن. لكن لا ينبغي لنا سرقة الرموز من الميزات الأخرى الممكنة (حتى لو كانت بعيدة جدًا).

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

يستخدم & كمرجع في بعض لغات البرمجة مثل C ++. أوافق أكثر على وجهة نظر ماكس بأنه يمكننا استخدامها كما يفعل Sass الآن في المستقبل:

.foo.bar .baz.bang, .bip.qux {
  $selector: &;
}

@ Seven-stage-max أعتقد أننا يجب أن نجعله نطاق البحث المختلط أولاً من البداية. اللغة أسهل في التعلم والقراءة إذا كانت تتصرف باستمرار. هناك عدد كبير جدًا من القواعد التي يجب تذكرها (imo) بالفعل ، ولن يؤدي إضافة قاعدة مخصصة جديدة إلى تسهيل الأمر.

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

انا اعتقد ان هذا:

#namespace() {
   padding-right: 2;
  .miniPadding() {
     padding-left: $padding-right - 1;
  }
}

.big-table {
   padding-right: 5;
  .sub-table {
    #namespace() > .miniPadding();
  }
}

يجب تجميعها إلى:

.big-table {
   padding-right: 5;
}
.big-table .sub-table {
   padding-left: 1;
}

قد يكون تجميعها على النحو التالي مربكًا / غير متوقع ويبدو وكأنه خطأ:

.big-table {
   padding-right: 5;
}
.big-table .sub-table {
   padding-left: 4;
}

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

أنت تصف سلوك الإغلاق الطبيعي. له معنى بالنسبة لي.

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

أعتقد أننا يجب أن نجعله يبحث عن نطاق mixin أولاً من البداية.

لكنني كتبت نفس الشيء تمامًا :) ( تحديث : . خطأ ، أعني "قصدت أن قواعد البحث عن الخاصية يجب أن تكون تمامًا مثل تلك الخاصة بالمتغيرات" ، (أكثر من ذلك ، أعرف أنها هي نفسها داخل المترجم لأنها نفس الكود الذي يعالج المتغيرات والخصائص (مع القليل من if s).

البحث من النطاق الحالي إلى أعلى.

هو اقتباس دقيق من Variables> Lazy-Loading .

بالحديث عن مثالك ، إنه غير سعيد تمامًا. لأن نفس المثال مع المتغيرات يتقدم إلى 1316 والنتيجة هي padding-left: 4; . أتفهم سبب استخدامك #namespace() هناك ولكن مع كل مشكلات "مساحة الاسم المحددة" يمكن أن يكون الأمر محيرًا للغاية. نحتاج إلى مثال آخر (لأن مثالك هو بالضبط المكان الأفضل لاستخدام المتغيرات بدلاً من الخصائص).

ملاحظة غريبة: في الأيام الثلاثة الماضية ، ظهرت أربع مشكلات مرتبطة مباشرة بـ # 1316 (# 2435 ، # 2350 ، # 2436 والآن مثالك) هل هي نوع من المؤامرة؟ :)

@ Seven-stage-max أسأت فهمك ونسيت # 1316. آسف على حد سواء :).

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

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

بالتأكيد أتفق مع SomMeri عندما يقول

هناك عدد كبير جدًا من القواعد التي يجب تذكرها (IMO) بالفعل "

وأعتقد أن نموذج الكود الخاص به https://github.com/less/less.js/issues/2433#issuecomment -73202522 بغض النظر عما يتم تجميعه إليه ، فهو معقد للغاية.

تعريف من ستايلس :

بحث عن خاصية

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

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

.mySquare {
  width: 200px;
  height: $width;
}
.myRectangle {
  width: 500px;
  height: $width / 2;
}

بمجرد قراءة height: $width; ، يعرف الجميع بالضبط ما يحدث هناك - إنه مربع ، بغض النظر عن أي شيء.

يجب مناقشة مناقشة التداخل وما إذا كان يجب البحث عن جميع المحددات الرئيسية في مكان آخر (# 1848).

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

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

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

كل هذه القضايا الأربع هي نفس المشكلة الأساسية؟ هل من السهل / صعب الإصلاح برأيك؟

نعم ، إنها نفس المشكلة الأساسية ولكن في معظم الحالات يتعلق الأمر بتوقعات مختلفة حول كيفية عمل هذه الأشياء (حول كيفية عمل تحديد النطاق وكيف يعمل في الواقع) وليس حقًا الرمز الذي يعاني من # 1316. ناقشنا الطرق الممكنة لإصلاح # 1316 نفسه حول https://github.com/less/less.js/issues/2212#issuecomment -57281241 (ليس بهذه السهولة ولكن من المحتمل أن يكون ذلك ممكنًا) ولكن هذه المشكلات (نصف المشكلات / نصف الميزة -الطلبات) التي ذكرتها (باستثناء المثال أعلاه بالطبع) تطلب في الواقع إصلاحها بطريقة معاكسة أو توفير باب خلفي لذلك (وبالتالي كسر السلوك الحالي الأقل ، المثال الجيد هو # 2435).

krnlde أنا آسف للتضليل ...

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

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

جاءت المتغيرات في ليس مباشرة من (أو مستوحاة من) سلوك الخصائص. في بعض المعالجات الأولية ، إذا قمت بتعيين متغير ، ثم قراءته ، ثم تعيينه ، ثم قراءته ، كل ذلك في نفس النطاق ، ستحصل على نتيجة مختلفة. في Less ، يشبه السلوك خصائص CSS: يفوز الإعلان الأخير في النطاق. لذا ، في الوقت الحالي ، هناك الكثير من التداخل بين المتغيرات والخصائص. إذا اتصلت بـ mixin ، فلن تحصل على خصائصه فحسب ، بل متغيراته. ويمكنك فعلاً القيام بأشياء مثل إضافة الخصائص معًا (أو بالأحرى إضافة قيمها) باستخدام بناء الجملة property+: و property+_: . الشيء الوحيد الذي لا يمكنك _ بعد_ القيام به هو الرجوع إلى الخاصية.

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

هناك عدد كبير جدًا من القواعد التي يجب تذكرها (imo) بالفعل

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

.block {
  <strong i="15">@height</strong>: 10px;
  width: <strong i="16">@height</strong> / 2;
}
.block {
  height: 10px;
  width: $height / 2;
}

الفرق هو أن الارتفاع ناتج كخاصية في الكتلة الثانية. لكن تحديد النطاق لا يتغير.

أو طريقة TL؛ DR لقولها: الخصائص في أقل ، بشكل عام ، تعمل بالفعل مثل المتغيرات ، لكن لا يمكنك الرجوع إليها. ستسمح هذه الميزة بالرجوع إلى الممتلكات.

طريقة أخرى لتوضيح ما ورد أعلاه:

//Less
.block {
  <strong i="7">@height</strong>: 10px;
  width: <strong i="8">@height</strong> / 2;
  <strong i="9">@height</strong>: 20px;
}
// output
.block {
  width: 10px;
}
//Less w/ property reference
.block {
  height: 10px;
  width: $height / 2;
  height: 20px;
}
//output
.block {
  width: 10px;
  height: 20px;
}

استوحى مثال krnlde عرضًا تجريبيًا آخر:

.square(@width) {
  height: @width;
}
<strong i="7">@row</strong>: 100px;
.column-2 {
  width: <strong i="8">@row</strong> / 2;
  .square($width);
}
.column-4 {
  width: <strong i="9">@row</strong> / 4;
  .square($width);
}


// output
.column-2 {
  width: 50px;
  height: 50px;
}
.column-4 {
  width: 25px;
  height: 25px;
}

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

باستخدام هذا التركيب الجديد ، يمكنني القيام بذلك على النحو التالي:

غير متوفر من مصدر آخر:

.divheader{
   height:50px;
   color: red;
   line-height: 1.5;
   width: 100px;
}

بلادي الأنماط.

.mydivheader{
   .divheader.height; //invented syntax
   .divheader.line-height; //invented syntax
   color: black;
}
//output
.mydivheader{
   height:50px; //inherited
   line-height: 1.5; //inherited
   color: black;
}

لذلك أرث فقط خصائص الارتفاع وارتفاع السطر لفئة divheader ...

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

إذا / عند التنفيذ ، سأرى بناء الجملة أقرب قليلاً إلى هذا:

.divheader{
   height: 50px;
   color: red;
   line-height: 1.5;
   width: 100px;
}
.mydivheader {
  height: ${.divheader > height};
  line-height: ${.divheader > line-height};
  color: black;
}

ومع ذلك ، نظرًا لأنك لا تقوم بحساب أي شيء ، فهناك بعض الخيارات الأخرى المتاحة لك الآن ، مثل:

<strong i="11">@divheader</strong>: {
  height: 50px;
  line-height: 1.5;
};
.divheader{
  @divheader();
   color: red;
   width: 100px;
}
.mydivheader {
  @divheader();
  color: black;
}

يمكنك أيضًا الحصول على مزيج يعين الخصائص ، أو استخدام :extend على مجموعة قواعد مشتركة. لذا بدلاً من الإشارة مباشرة إلى فئة أخرى ، يمكنك الحصول على قسمين من div يشيران إلى مجموعة قواعد أخرى منفصلة أو mixin.

+1 أتفق تمامًا مع Justineo :
"_أعتقد أنه ليس ضروريًا ولكن من الجيد أن يكون لديك. يمكن للمتغيرات القيام بالمهمة ولكن مراجع الخاصية المباشرة أكثر قابلية للقراءة ._"

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

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

jlem هناك علاقات عامة جارية بالفعل (عملت عليها - https://github.com/less/less.js/pull/2654) ، وتعمل بشكل أساسي ، ولكن هناك بعض المشكلات الصغيرة التي يجب حلها. حالة استخدام مثيرة للاهتمام ، لكن هذا لن ينطبق هنا ، حيث لن يمكن الوصول إلى الأنماط الأخرى بواسطة Less.

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

لاحظ أنه تم تطبيق الإشارة المرجعية للخاصية البسيطة ( $prop ) ، لكن لم يتم توثيقها (AFAIK).