Less.js: الخصائص المخصصة داخل الدوال المضمنة مثل `` rgba () `رمي الخطأ

فقط اهرب .

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

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

أقل ، AFAIK ، ليس لديها أيضًا اختبارات للطبيعة المتساهلة للغاية لقيم الخصائص المخصصة. يمكن أن تحتوي على أي شيء إلى حد كبير ، حتى الفاصلة المنقوطة ، طالما أنها ليست رموزًا عالية المستوى (غير موجودة في أزواج الأقواس أو الأقواس المتعرجة). راجع: https://www.w3.org/TR/css-variables/#syntax

نظرًا لأن هذا التغيير يتطلب التحقق من n-of-args على أي حال (للاحتفاظ ببعض التحقق من الأخطاء على الأقل داخل الوظائف) ، فمن المفترض أيضًا أن التطبيق الأحدث rgba يدعم أيضًا نموذج الوسيطتين لقيم الألوان الترتيبية ، على سبيل المثال :

rgba(var(--some), .42); // -> rgba(var(--some), .42)
rgba(#010101, .42); // -> rgba(1, 1, 1, .42)

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

أرى مجموعة كاملة من وظائف CSS المضمنة على https://github.com/less/less.js/blob/master/lib/less/functions/color.js#L34 ، ولا ينبغي أن يكون معظم ذلك في IMO كن هناك. الأقل ليس لينتيرًا ، وهذه ليست وظائف أقل. إذا حاول المحلل اللغوي الحصول على مهارات فائقة في وظائف CSS ، فسوف يفشل. لذلك أعتقد أن هذا هو مصدر المشكلة ، أن Less هو حاليًا وظائف ألوان CSS عادية ترقيع القرود بدلاً من السماح لها بالمرور.

لست متأكدًا مما إذا تمت إضافة ذلك للمتصفحات التي لم تدعم بعد rgb() rgba() ؟ يبدو أنه تمت إضافته منذ 4 سنوات. ربما كان السبب المنطقي هو إضافة توازن إلى وظائف الألوان الأحدث التي لم يتم دعمها بعد في المستعرضات؟ 🤔lukeapage أنت لا تزال في جميع أنحاء لالجواب؟

بالنظر إلى تعليقي في # 3214 ، فإن الحل السريع لهذه المشكلة سيكون فقط: "إذا (nargs <3/4) الرجوع إلى سلسلة css (بعدم إرجاع أي شيء)" في تطبيقات الوظائف المقابلة.

(ويتمثل الإصلاح الأكثر صرامة في إجراء عمليات تحقق لكل وسيطة في كل وظيفة لتحديد ما إذا كانت قابلة للتقييم وإرجاع إما كائن ملون أو سلسلة CSS احتياطية).

بالنظر إلى تعليقي في # 3214 ، فإن الحل السريع لهذه المشكلة سيكون فقط: "إذا (nargs <3/4) الرجوع إلى سلسلة css (بعدم إرجاع أي شيء)" في تطبيقات الوظائف المقابلة.

وشيك مماثل var() ؟

darken(rgba(var(--red-value), 2, 3, .4), 5%)

وهو: هل يجب أن نفعل ما يلي:

1. السماح بتمرير الدوال إذا لم تتطابق مع n-args؟ أفترض أننا سنحتاج إلى وضع علامة على الوظائف بشكل خاص نظرًا لأنه لا يوجد شيء مميز حول تسجيل الوظائف (ما لم نفعل شيئًا مجنونًا مثل toString() الوظيفة ونعد الأرقام حرفياً باستخدام regex - AFAIK هو النوع الوحيد من الانعكاس في JS ؛ أنت قد يكون قادرًا على القيام بذلك باستخدام TypeScript ولكن هذا لا يساعدنا)
2. خطأ في الرمي إذا تم استخدام دالة غير مطابقة في تقييم دالة أقل.

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

هذه مشكلة مثيرة للاهتمام لأن إدخال الخصائص المخصصة جعل وظائف CSS غير قابلة للحل في وقت الترجمة.

لا شيء جديد حقا. كل التسهيلات اللازمة للتعامل مع هذا الأمر مع Less موجودة منذ الإصدار 1.x - انظر أدناه. التحدي الوحيد هو ترميزها بطريقة غير منتفخة.

أفترض أننا سنحتاج إلى تحديد الوظائف بشكل خاص نظرًا لعدم وجود شيء خاص حول تسجيل الوظيفة

لا ، يجب أن تقوم الوظائف بإرجاع undefined (أو null ) إذا وجدوا أنهم لا يستطيعون تقييم حججهم: مثل هذا (ما لم يكتشفوا أيضًا أن الأرجل غير منتظمة بنسبة 100٪ ومن الأفضل أن يؤدي إلى حدوث خطأ). .
وقيمة الإرجاع غير المحددة تجعل مقيم الوظيفة يتراجع إلى تمثيل السلسلة الأولي: Demo .

وشيك مماثل var()

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

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

@ Seven-stage-max حسنًا ، لذلك تعتقد أن الإصلاح البسيط هو أن تقوم وظائف CSS / Less بإرجاع غير محددة بدلاً من طرح خطأ (لتقديمها كما هي)؟ يبدو ذلك معقولًا ، إذا كانت الوظيفة لا. 2 (مثل darken() ) لا يمكنه تفسير الوسيطة (التي سيتم تقييمها في هذه المرحلة إلى قيمة rgba() مجهولة؟) ، يجب أن لا يزال؟

أتجادل مع نفسي:

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

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

@ ماثيو دين

يبدو ذلك معقولًا ، إذا كانت الوظيفة لا. 2 (مثل darken ()) لا يمكنها تفسير الوسيطة (التي سيتم تقييمها في هذه المرحلة إلى قيمة rgba () مجهولة؟) ، فلا يزال يجب أن ترمي؟

نعم ، بالضبط - لا نحتاج حتى إلى أي رمز جديد لهذا (على الرغم من أنه من الناحية المثالية يجب أن تحتوي (وظائف مثل darken ) على رسائل خطأ أكثر ودية في هذه الحالة لأن الرسائل الحالية "a.toHSL is not a function" -like هي مربكًا جدًا).

حسنًا ، الشيء الآخر الذي لم يتم ذكره هو أن المتصفحات تعامل شيئًا مثل rgba(calc(1),1,1) على أنه صالح (لاحظ كلاً من الوسيطات calc و 3 مقابل 4) ، لذلك ربما لا ينبغي لنا أن نكون أكثر ذكاءً حيال ذلك. تعجبني فكرة الإخراج كما هي كقاعدة عامة ، إن أمكن.

نعم ، هذا ما أعنيه به

يجب أن يتحقق الكود مما يمكن تقييمه (الأشياء المعروفة) بدلاً من ما لا يمكن تقييمه (المجهول).

الوسائط الصالحة الوحيدة لـ Less rgba هي إما رقم أو كائن ملون (إذا أخذنا في الاعتبار أيضًا النماذج الشبيهة بـ "neo" - "CSS4" مثل rgba(#123, .42) ).
أي شيء آخر إما خطأ أو قيمة CSS (غير معروفة ولكن من المحتمل أن تكون صالحة).

يعتبر بناء جملة محتوى خصائص CSS المخصصة متساهلًا للغاية ولكن هذا يسبب مشاكل عند استخدام مثل هذه الخصائص داخل وظائف مضمنة مثل rgba()

مثال:
يسمح مشروعي للمستخدم بتحديد لون التمييز الذي تستند إليه واجهة مستخدم التطبيق بالكامل ومختلف المكونات المخصصة. وأنا أستخدم تنسيق rgb بسبب الحاجة إلى التلاشي في أماكن معينة ولا يوفر CSS أي شيء مثل fade(<strong i="9">@color</strong>, 50%) بأقل من ذلك. بهذه الطريقة يمكنني أن أفعل rgba( var(--color), 0.5 ) . هذا يعمل في Chrome ويدعمه ستاندارت. ومع ذلك ، ألقى أقل الخطأ التالي error evaluation function 'rgba': color functions take numbers as parameters .

رمز المثال:

:root {
  --color-accent: 169,57,255;
}
button:hover {
  background-color: rgba(var(--color-accent), 0.2);
  color: rgb(var(--color-accent));
}

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

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

اكتب مثل هذا ~

:root {
    --color-accent: 169,57,255;
}
button:hover {
    background-color: ~"rgba(var(--color-accent), 0.2)";
    color: ~"rgb(var(--color-accent))";
}

weivea في أحدث إصدار من أقل 3.x ، هذا ليس ضروريًا ، فقط اكتب rgba(var(--color-accent))