Less.js: كيفية التعامل مع الرياضيات

لا أعتقد أننا نريد تغيير الأشياء بشكل كبير أو العودة إلى لوحة الرسم

نعم ، لقد اقترحت أن نبدأ هذا فقط لأننا _if_ نريد بعض العمليات الحسابية الصارمة "الافتراضية" في الإصدار 3.0 ، وعلينا أن نبتكر شيئًا أقل ثقلاً من الحالي (وإمكانية حل جميع المشكلات دون تقديم أي --alt-strict-math يبدو أن الخيار font ...).

لم أكن أدرك أنه ينمو

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

أعتقد في الوقت الحالي أنني أؤيد التوسع في الرياضيات الصارمة في البداية

• إيقاف
• قسم
• تشغيل

ثم بالنسبة لـ 2.0.0 ، يتم تعيين الإعداد الافتراضي ليكون القسمة

لذا..

استعلامات الوسائط - إذا تم إيقاف تشغيلها ، فانتقل إلى التقسيم للعقد الفرعية
الخط - في حالة إيقاف تشغيله ، قم بالتبديل إلى القسمة للعقدة الفرعية
calc (- إذا تم إيقاف تشغيله أو تقسيمه ، فقم بتشغيله للعقد الفرعية

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

نعم ، أعتقد أنهم يتجهون إلى السماح بـ "قيم الاختزال" (على سبيل المثال x/y ) في _ أي _ "خاصية shorhand" ...

ذات صلة: https://github.com/less/less.js/issues/1480

خيار آخر .. معالجة مكالمات الكسب ولكن فقط عندما تجعل الوحدات ذلك ممكنًا على سبيل المثال
احسب (1٪ + 2٪) => 3٪
احسب (100٪ - 10 بكسل) => دون تغيير

سيؤدي هذا إلى إصلاح calc ولكنه لن يصلح # 1627 والأشياء ذات الصلة.
أعني نعم ، يمكن أن يكون calc(100% - 10 px) => unchanged حلاً لـ calc لكن هذا لا يلغي الحاجة إلى حل less-heavy-than-parens-everywhere .

إذا تمت إعادة النظر في الرياضيات الصارمة ، أود أن أقترح أن الدالات الأقل مثل percentage() لا تتطلب أقواسًا إضافية بداخلها. مع العمليات الحسابية الصارمة ، عليك أن تكرر الحجة مرتين. سيقلل هذا بشكل كبير من احتمالية حدوث ارتباك وصعوبة اكتشاف الأخطاء ، نظرًا لأن كلا من percentage(16 / 17) و percentage((16 / 17)) سيكونان صالحين.

يوفر calvinjuarez V2 نظامًا فرعيًا للمكوِّن الإضافي حيث يمكن 16/17 ، ثم تقييم 16/17 _ قبل_ أن يتم تمريره إلى دالة سيكون غير صحيح (حسنًا ، تقريبًا - إنه أكثر تعقيدًا قليلاً من ذلك داخليًا).

في هذا السياق ، يبدو أن التغيير ./ هو المفضل لدي على الرغم من أنني أفهم أنه سيكون تغييرًا كبيرًا للغاية (إذا ما قورنت بـ (/) ، فإن عدم احتسابه يتطلب أيضًا مسافة بيضاء قبل . ، على سبيل المثال 16 ./17 وليس 16./17 ، hmm).

هناك شيء آخر حيث يكون عدد أقل من فواصل css الصالحة حاليًا هو اختصار الخلفية:

background: url(image.png) 50%/300px no-repeat;

أعتقد في الوقت الحالي أنني أؤيد التوسع في الرياضيات الصارمة في البداية

إيقاف
قسم
تشغيل
ثم بالنسبة لـ 2.0.0 ، يتم تعيين الإعداد الافتراضي ليكون القسمة

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

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

يُسمح بقبول 16/17 ، ثم تقييم 16/17 قبل أن يتم تمريرها إلى دالة سيكون غير صحيح

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

يمكن أن تكون خياراتنا الرياضية مثل:

• دائما
• تقسيم (افتراضي)
• صارم

لذلك ، يمكننا إهمال --strict-math = true وجعلها اسمًا مستعارًا لـ --math =rict

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

مسموح لهم بالفعل (فقط اختبر كيفية عمل percentage(16 / 17) و percentage((16 / 17)) مع --strict-math=on ).
على الرغم من عدم استخدام أي من الوظائف:

ومن ثم يمكن لدالة النسبة المئوية إجراء استدعاء لبعض الوظائف المساعدة لمعرفة ما إذا كان النص رياضيات.

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

يجب أن تحتوي كل وظيفة على 20 سطرًا إضافيًا؟ كيف يمكنك معرفة؟

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

يجب أن تحتوي كل وظيفة على 20 سطرًا إضافيًا؟ كيف يمكنك معرفة؟

هذه مجرد مبالغة نموذجية لـ: ربما 5 ، ربما 10 ، ربما 20 ... من سيهتم بالأرقام الدقيقة إذا كانت نسبة الكود الحقيقي / الكود الإضافي -> 0 . (باتباع نهج عملي ، سأتوقف عند percentage(16 / 17) فقط أرتكب خطأً بدلاً من إنتاج NaN% (كما هو الحال الآن) ، ولا أحاول إجراء أي تحويل ... على الرغم من أنه لا يزال بهذه الطريقة 4 أسطر إضافية من التعليمات البرمجية - حسنًا ، مقبول أقل أو أكثر على ما أعتقد :)

كان ردي الأولي يشير إلى أنه يفترض أن هذا التحويل 16/17 -> (16/17) سيتم إجراؤه ضمنيًا بواسطة المترجم نفسه (وليس بواسطة الوظيفة).

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

كنت أفكر فقط أنه سيكون شيئًا مثل:

percentage: function(...) {
  Helper.convertMath(arguments);  // a function that doesn't need it doesn't call it
  // ... the rest
} 

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

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

Helper.convertMath(arguments);

arguments متفائل للغاية.
في أحسن الأحوال (بحساب ليس فقط percentage - وهو نوع عديم الفائدة على أي حال ، لكن أي دالة أخرى تتوقع وسيطة رقمية) فإن الحد الأدنى من المتطلبات سيكون:

some: function(a, b, c) { 
    a = convert2number(a, "Error message when fails"); 
    // b is not a number for example
    c = convert2number(c, "Error message when fails"); 
} 

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

نعم ، فهمت لك.

percentage(16 / 17) تسبب فقط في حدوث خطأ

سيكون تحسنا بالتأكيد. (لا أستطيع التفكير في أي وقت أن NaN% سيكون ناتجًا مفيدًا.)

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

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

تحرير: في الواقع ، فقط عندما يتم تمرير دالة رياضية واحدة فقط.

ما هو الوضع على هذا؟ نتلقى شكاوى من أن LESS يحاول تحليل خصائص CSS غير الصالحة على أنها رياضيات. على سبيل المثال ، فواصل lost-column: 1/3; .

يبدو أيضًا أن http://www.w3.org/TR/css-grid-1/#grid -template-rowcol لن يعمل مع LESS.

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

corysimmons ألم تسأل هذا للتو على # 2769 وتحصل على إجابة؟ o_O

شيء واحد لم نناقشه عندما حدث هذا في المرة الأولى. يبدو أن الصراع الحقيقي الوحيد في الرياضيات هو الانقسام. والانقسام هو في الأساس قضية لأننا في الأساس نقوم "بإعادة توظيف" شخصية "فصل" في CSS.

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

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

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

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

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

علامة القسمة هي أيضًا مكافئة رياضيًا لرمز النسبة ، ويُشار إليها عادةً بنقطتين (:) وتقرأ "هو إلى". وبالتالي ، بالنسبة لأي عدد حقيقي x وأي عدد حقيقي غير صفري y ، فإن هذه المعادلة تحمل:

س ÷ ص = س: ص

بعبارات أخرى:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 

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

أفكار؟

_بدلاً من ذلك_ ، لا يزال بإمكاننا دعم رمز القسمة بين الأقواس و / أو الأقواس ، كما في:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 
lost-column: (1/3);
lost-column: [1/3];

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

.foo(<strong i="9">@a</strong>: 1, <strong i="10">@b</strong>: 2) {
  result: <strong i="11">@a</strong> @b;  
}

bar {
    <strong i="12">@b</strong>: 4;
    .foo(<strong i="13">@b</strong>:3); // would mean both @second-parameter:3 and 4/3
}

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

القراءة مرة أخرى ، إلى هذه النقطة:

بدون حساب يتطلب أيضًا مسافة بيضاء قبل . ، على سبيل المثال 16 ./17 وليس 16./17

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

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

أعتقد أنه بغض النظر عن كيفية كتابتك ، سواء كانت مسافة بيضاء أم لا ، يجب أن تقسم 16 على 17.

نعم فعلا.
على الرغم من التفكير في الأمر أكثر ، أتوقع أن يضع ./ بعض الحيل الإضافية للمحلل اللغوي (سيحتاج تحليل الأرقام إلى مزيد من التطلع إلى الأمام للتوقف قبل ./ بينما حاليًا يأكل دائمًا . ).

وخصوصًا لأنه مطلوب فقط بسبب الانقسام ، على حد علمي. نعم؟)

نعم بالضبط. لا يتم احتساب الكود الموجود داخل calc - ولكن بالنسبة لهذا الرمز ، أعتقد أن الحل الذي اقترحه lukepage يجب أن

(من الناحية الفنية ، قد يكون هناك بعض الغموض الإضافي في المستقبل لـ +, -, * إذا ظلوا في بناء جملة وظائف معالجة ألوان CSS - لكن هذا لا ينبغي أن يكون دراماتيكيًا جدًا نظرًا لأن القيم هناك تحتوي على * 20% النموذج (وبالتالي من الواضح أنه يمكن اكتشافها على أنها بعض expr غير المقيم). بعد كل هذه المرح سوف تحتاج إلى بعض تغييرات التحليل على أي حال لأن القيم الحالية مثل (* 20%) تسبب خطأ في التحليل).

ربما ... كنا نتعامل مع كل هذا بشكل خاطئ. (بالتأكيد أشركني في ذلك ، نظرًا لأنني كنت مؤيدًا قويًا أوليًا لميزة "الرياضيات الصارمة".)

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

المثال calc(100% - 10px) هو المثال الأكثر وضوحًا. لا توجد عملية حسابية أقل يمكن / يجب إجراؤها ما لم نقم بإلقاء الوحدات ، وهو ما أوافق على أنه يجب على الأقل التوقف عن القيام به افتراضيًا. ¹

لنلقِ نظرة على خاصية اختزال الخط المستخدمة كمثال.

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
font: italic bold 12px/30px Georgia, serif;

الحل الحالي لهذا هو تحويل strict-math: on لخاصية الخط. لكن ... لماذا يجب على Less أن يقوم بأي حسابات في المقام الأول؟ بالتأكيد ، 13px/150% عبارة صحيحة في الرياضيات ، لكن هل من المعقول معاملتها على أنها صحيحة في Less؟ 12px/30px أنت _ يمكن أن تتعامل معه على أنه بيان رياضيات صالح ، لكن هل يجب عليك ذلك؟ ²

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

بمعنى أنه من المعقول أن تطلب من شخص ما كتابة 13px/150% كـ 13px/1.5 . وحتى تجاهل حقيقة أن 12px/30px لن يكون منطقيًا كعملية حسابية ، لسنا بحاجة إلى معرفة أنها ليست كذلك ، ولسنا بحاجة إلى القائمة البيضاء font . إذا كان المؤلف الأقل يقوم بعملية حسابية ، فمن المعقول أن يكتبها 12px/30 . لن يكون ذلك منطقيًا فحسب ، بل إنه احتمال كبير جدًا _ كيف يكتبونه في المقام الأول _.

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

width: <strong i="5">@size</strong> / 2;
height: <strong i="6">@size</strong> / 2;

لماذا أكتبه بهذه الطريقة؟ هل _ أي شخص_ يكتبها بهذه الطريقة؟

width: <strong i="10">@size</strong> / 2px;
height: <strong i="11">@size</strong> / 2px;

تكون العملية _sort of_ منطقية إذا كان @size وحدة px ، ولكن ، بغض النظر ، سيكون أقل منطقية في مجال LESS / CSS لمحاولة القيام بالرياضيات في الحالة الأخيرة عندما يكون المقسوم عليه هي قيمة بوحدة. الثاني لا يشبه الرياضيات. تبدو كقيمة CSS.

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

<strong i="18">@pad</strong>: 2px;
width: 10px + @pad; 

ولكن عند إضافة / طرح قيمة واحدة مع وحدة إلى أخرى مع وحدة مختلفة ، يجب أن تترك القيمة الأقل بمفردها.

<strong i="22">@val1</strong>: 100%;
<strong i="23">@val2</strong>: 10px;
width: calc(<strong i="24">@val1</strong> - @val2);

// output
width: calc(100% - 10px);

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

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

background: no-repeat 10px 10px/80% url("../img/image.png");

% هي وحدة CSS. px وحدة CSS مختلفة. لذلك ، لا الرياضيات. الاستثناء الخاص سيكون صفرًا.

background: no-repeat 0 0/80% url("../img/image.png");

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

نصف قطر الحدود ، نفس الشيء:

border-radius: 30% / 20%;

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

border-radius: 30% / 0.2;

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

هناك حالة واحدة يمكنني التفكير فيها ، وقد تكون هناك حالة أخرى:

font: 10px/1.5;

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

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

أرحب بردود / تعليقات المعرض.

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

فقط لبعض السياق التاريخي ، من المهم ملاحظة أن وحدات الصب عند إصدار Less.js لأول مرة لم تكن مشكلة كبيرة. لم يتم تنفيذ calc() ولم يكن background و border-radius مائلين كقيم صالحة. أعتقد أن font كان المكان الوحيد الذي أفسد الأمور (والذي ، من المفارقات ، ربما لا يزال كذلك).

شاغلي الوحيد هو جانب التنفيذ ، على سبيل المثال: بالنسبة إلى calc(4px + 2rem + 20%) (الوحدات الفعلية لا تهم) ، ينتج عن الإضافة الأولى نتيجة ليست رقمية بعد الآن ، وبالتالي لا يستطيع معالج الإضافة الثاني تمييز مدخلاته عن مهما كانت عبارة not-a-number + 20% حيث يجب أن تسبب خطأ. ربما لا تكون مشكلة كبيرة (قابلة للحل عن طريق وضع علامات إضافية من النوع / النوع) ، ولكنها لا تزال بحاجة إلى بعض التحقيق.

والشاغل الآخر هو إيههم ، لست متأكدا ، "ردابيلتي"؟ أي بينما بالنسبة للأرقام الصريحة ، تبدو النتيجة واضحة تمامًا ، بالنسبة للمتغيرات تبدأ في الظهور بشكل غامض تمامًا ، على سبيل المثال: border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - لا تعرف أبدًا ما الذي يفترض أن يعنيه هذا حتى ترى @a و @b تعريفات.

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

ملاحظة: هناك مشكلة أخرى (ربما تراجع طفيف) .هناك قيم مثل:

border-radius: 10px / auto;
border-radius: 1px inherit / 2px;
background: ... center / 80% ...;
// etc.

أي لكي يعمل كل شيء ، سيتعين علينا تعطيل أي أخطاء غير متوافقة حاليًا في معامل div بحيث يمكن تمرير أي foo/bar و 1x/bar و foo/1x توقف خطأ.

شاغلي الوحيد هو جانب التنفيذ ، على سبيل المثال: لـ calc (4px + 2rem + 20٪) (الوحدات الفعلية لا تهم)

هذا ما اقوله. يجب أن تكون الوحدات الفعلية مهمة. القليل يجب أن يترك ذلك بمفرده ، بغض النظر. 4px + 2rem له معنى في المتصفح ، لكنه لا معنى له في أقل. لا يوجد سبب لمحاولة إضافته عندما لا يكون له معنى ، ويسبب مشكلات الوظائف الإضافية هذه.

على سبيل المثال: border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ؛ - لا تعرف أبدًا ما يفترض أن يعنيه هذا حتى ترى تعريفات @a و @b .

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

مع قواعد الرياضيات هذه التي أقترحها ، ضع في اعتبارك:
calc(4px + 2rem - 2px)

يمكن أن يحسب الأقل ذلك على أنه calc(2px + 2rem) ، وهو أمر جيد تمامًا ، وهو في الواقع ناتج ذو قيمة صحيحة. في الوقت الحالي ، يحسبها Less على أنها calc(4px) ، وهي ليست إجابة صحيحة أو مفيدة. (نعم ، هذا صحيح حاليًا إذا أسقطنا الوحدات ، لكن الوحدات لا معنى لها ، وباستثناء حالات قليلة ، لا يمكن تشغيلها بشكل متبادل.) أقل يحسب 2px + 100% كـ 102px ، كما لو أن هناك بعض القيمة في تلك النتيجة ، عندما لا أحد يريد ذلك كنتيجة.

لكي يعمل الأمر برمته ، سيتعين علينا تعطيل أي أخطاء غير متوافقة حاليًا في معامل div بحيث يمكن لأي foo / bar و 1x / bar و foo / 1x اجتياز خطأ w / oa.

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

أقل يمكنه / سيحسب ذلك كما هو محسوب (2 بكسل + 2 ريم)

أخشى أنه لن يحدث أبدًا لأن هذا سيتطلب معالج تعبير محسن جديد تمامًا والذي سيكون مبالغة (بشكل أساسي 4px + 2rem - 2px يتم تخزينه في الشجرة كـ (4px + 2rem) - 2px لذلك للحصول على 2px + 2rem يجب أن يكون محركًا لإعادة الطلب لتجربة جميع عمليات الخلط الصحيحة (تافهة في هذه الحالة بالذات ولكنها تصبح معقدة جدًا لمزيد من المعامل / المشغلين). لكن لا تهتم ، ترك 4px + 2rem - 2px كما هو جيد (بعد كل شيء إذا كنت تفعل 4px - 2px + 2rem فسيتم تحسينها).

لكن ما قصدته بالفعل بهذه الملاحظة هو الشيء المشابه لـ:

بحيث يمكن لأي foo / bar و 1x / bar و foo / 1x اجتياز خطأ w / oa.

أي (4px + 2rem) - 2px لـ expr.evaluator سيكون مشابهًا لـ foo + 2px ، وبالتالي لن ينتج عن العمل أخطاء لهذا النوع من الأشياء أيضًا.
في الواقع ، لقد اختبرت foo/bar, 1x/bar, foo/1x وقد مروا بالفعل بأخطاء (من الغريب أنني اعتقدت أنهم يرمونها) ، لكن المشغلين الآخرين ينتجوا كل أنواع الأشياء الغريبة (لا يوجد شيء مهم حقًا ، فقط مسألة إصلاح كل حالة واحدا تلو الآخر).

أخشى أنه لن يحدث أبدًا لأن هذا سيتطلب معالج تعبير جديد تمامًا والذي سيكون مبالغة (بشكل أساسي يتم تخزين 4 بكسل + 2 ريم - 2 بكسل في الشجرة كـ (4 بكسل + 2 ريم) - 2 بكسل لذلك للحصول على 2 بكسل + 2 ريم) أن تكون محركًا لإعادة الترتيب لتجربة جميع عمليات الخلط الصحيحة (أمر تافه في هذه الحالة بالذات ولكنه يصبح معقدًا جدًا لمزيد من المعامل / المشغلين).

لماذا الخلط؟ تقوم بتسوية عوامل التشغيل بنفس مستوى الأولوية (بحيث تكون الشجرة Sum(4px, 2rem, -2px) ) ، وتجمع المصطلحات مع الوحدات المتوافقة (ربما عن طريق تسوية الوحدات مسبقًا) ، وتبسيط كل جزء. إنه جبر رمزي ، حيث يتم التعامل مع الوحدات كمتغيرات مستقلة.

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

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

تقوم بتسوية عوامل التشغيل على نفس مستوى الأولوية (بحيث تكون الشجرة هي Sum (4 بكسل ، 2rem ، -2 بكسل)) ،

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

ولكن هناك الكثير من المكتبات التي من المحتمل أن تكون مختبرة بشكل أفضل ومن المرجح أن تكون كاملة.

لست متأكدًا مما إذا كنت جادًا. هل تعتقد أن كل هذه التعليمات البرمجية لتحويل شجرة أقل إلى شجرة lib خارجية والعودة (بدون احتساب أي من هذه الكودات JS libs يمكنها التعامل مع وحدات CSS) تستحق في الواقع أن يتم تحسين حالة 4px + 2rem - 2p ؟ همم...

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

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

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

لست متأكدًا مما إذا كنت جادًا. لذلك تعتقد أن كل هذا الرمز لتحويل شجرة Less إلى شجرة lib خارجية والعكس

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

(بدون احتساب أيا من هذه JS libs يمكنها التعامل مع وحدات CSS)

كنت ستحول الوحدات إلى متغيرات جبرية. يمكن إجراء البدائل (على سبيل المثال mm -> px ) عندما يكون التعبير في شكل رمزي.

هل يستحق في الواقع تحسين حالة 4px + 2rem - 2p المحددة؟

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

يمكن أن يحل التبسيط الجبري الأشياء باستخدام تعبيرات فرعية بين أقواس ، ويسمح لـ Less بإضافة المزيد من ميزات الرياضيات.

حاول والعلاقات العامة موضع ترحيب.

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

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

أنا أعرف. كنت هنا لأحد الأسباب. لماذا هذه العضة؟

لماذا هذه العضة؟

حسنا، ربما ... إذا كان الأمر كذلك - اعتذاري (يبدو أنا فقط صدمت جدا من الجهد والوقت هناك من هو على استعداد لتكريس حل الى حد كبير لا القائمة calc(4px + 2rem - 2px) المشكلة ربما لدينا فقط مفهوم مختلف للغاية. من خفة الوزن).

والسماح لـ Less لإضافة المزيد من ميزات الرياضيات.

هل يمكنك تسمية القليل؟

لحل مشكلة غير موجودة إلى حد كبير calc(4px + 2rem - 2px)

هاه؟ أقل لا يستطيع التعامل مع ذلك على الإطلاق. [تم حذف الباقي لأنني أخطأت في فهم ما تم تناوله]

لتبسيط / إعادة صياغة الاقتراح - ستكون تغييرات الرياضيات على النحو التالي

1. سيتم حساب الجمع والطرح فقط على وحدات متشابهة. على سبيل المثال ، 1px + 2px = 3px ، 1px + 1vh = 1px + 1vh
2. سيتم حساب القسمة والضرب فقط باستخدام قواسم / مضاعفات بدون وحدة. على سبيل المثال ، 10px/2 = 5px ، 10px/5px = 10px/5px
3. سيتم التعامل مع نسب القيمة بدون وحدات بشكل مشابه لـ # 2. على سبيل المثال 1/3 = 1/3
4. للتبسيط ، يمكن التعامل مع التعبيرات ذات التعبيرات الفرعية غير الصالحة جزئيًا على أنها تعبير رياضي غير صالح وإخراجها كما هي. على سبيل المثال ، 1px + 2vh / 2 = 1px + 2vh / 2

يحل هذا الاقتراح ما يلي (من هذا الموضوع):

• بناء جملة font: 10px/5px وما شابه (نسبة) (بدون حساب)
• calc(100vh - 30px) (بدون حساب)
• lost-column: 1/3 وصيغة النسبة المخصصة المماثلة (بدون حساب)

في الوقت نفسه ، ستحافظ هذه التغييرات على 99٪ من الاستخدام المعتاد للرياضيات. بالإضافة إلى ذلك ، تسمح الوظائف الحالية unit() و convert() للمستخدمين بإلقاء القيم في وحدات متوافقة للرياضيات.

أقل لا يستطيع التعامل مع ذلك على الإطلاق.

أنت فقط لم تقرأ ما كنت أتحدث leewz أعلاه. لا علاقة له بـ calc(100vh - 30px) . و "لحل مشكلة غير موجودة إلى حد كبير" يذهب فقط إلى "تحسين التعبيرات الحسابية في calc ".

@ سبع مراحل - ماكس أوه ، حق ذلك. آسف. لا ، لسنا بحاجة إلى التحسين. فقط اكتشف متى تقوم بالرياضيات.

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

إزالة ملصق القائمة لأن المشكلة لا تزال مهمة وتزداد سوءًا مع تطور CSS.

@ ماثيو دين
سوف ألعب دور محامي الشيطان للحظة هنا ...

12px/30px أنت _ يمكن أن تتعامل معه على أنه بيان رياضيات صالح ، لكن هل يجب عليك ذلك؟

نعم؛ يجب. يحسب قيمة قياسية تمثل نسبة بين كلا الحجمين ويمكن أن تكون مفيدة جدًا عند التحويل إلى وحدة em.

لنفترض أن لدي حجم خط أساسي معروف يبلغ 16 بكسل وحجم عنوان معروف يبلغ 24 بكسل ، وكلاهما مخفي في المتغيرات ، وبعد ذلك أريد تعيين طابع معين للعنوان بحجم الخط الصحيح ، ولكن في وحدة em.

@fontsize-body    : 16px;
@fontsize-heading : 24px;

// ( ... and then somewhere else ... )

.heading {
  font-size : unit(@fontsize-body/@fontsize-heading, em);

  // Or if dividing compatible unit values is produces a unit-less scalar
  // value ( as it really _should_ -- mind you... ),  you could prefer:
  font-size : @fontsize-body/@fontsize-heading * 1em;
}

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

تم منح ذلك الآن ، قد يتضمن ذلك استخدام الأقواس لفرض تعبير رياضي واتخاذ CSS حرفيًا افتراضيًا. لكن هذا يبدو خطأ وعرضة للخطأ. يتطلب الكثير من الحالات الخاصة المطبوخة مسبقًا مثل اختصارات border-radius و font ، ويتطلب ذلك Less أن يحافظ على تحديثه باستمرار. (كما تم توضيحه من خلال بعض خصائص الشبكة الجديدة التي تطورت نفس المشكلة مع علامة القسمة.)

لذا...

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

رؤيتي الحالية للاقتراح:

• توقف عن معاملة / كقسمة في أي مكان بغض النظر عن أي untis وبغض النظر عن أي خيارات (ما لم - اختياريًا - يتم تضمينها بواسطة أقواس زائدة عن الحاجة مثل with -sm = on)
  وبالتالي لا يتم تقييم سوى 1anything./3whatever و (اختياريًا) (1anything/3whatever) بواسطة أقل.
• + و - و * تبقى دون تغيير
• calc subissue يتم حلها من خلال عدم تقييم أي حساب. التعبيرات داخل calc(...) (بالرغم من ذلك ، مرة أخرى ، قد يكون للأقواس المتقلبة تأثيرها أيضًا).

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

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

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

إن مشكلة ذلك متأصلة بشكل لا يصدق كعامل قسمة.

ليس في CSS.

لحالة الاستخدام الاستثنائي (/ في اختصارات CSS) التي نادرًا ما يستخدمها أي شخص.

حتى الآن / يستخدم بالفعل الكثير ، وبالمقارنة انها شعبة المرجع أقل هو تماما أكثر من ذلك بكثير استثنائية من CSS / في هذه الأيام (على عكس ذلك كان قبل سنوات قليلة حيث CSS / يمكن العثور على font فقط).

@ سبع مراحل كحد أقصى شكرا لمتابعتها. لقد أضفت برنامج Stale bot لمساعدتنا في إدارة المشكلات وأعطيت قدرًا كبيرًا من الوقت لوضع العلامات التي لا معنى لها. لقد استثنيت أيضًا تصنيفين ، "bug" و "up-for-grabs". نرحب بأي اقتراحات بشأن ذلك ، مثل التصنيفات الأخرى في القائمة البيضاء. الملف موجود هنا: https://github.com/less/less.js/blob/3.x/.github/stale.yml

العودة إلى موضوع المشكلة ...

تضمين التغريدة
حالة الاستخدام الخاصة بك تخلق مشكلة تعسفية. الحجة هي أنها مفيدة. لكن هيكلة المتغيرات الخاصة بك بهذه الطريقة يخلق مشكلة يمكن تجنبها من خلال بناء الجملة ، كما أوضح @ Seven-stage-max ، غامضة.

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

إذن ، الجواب البسيط هو أن مثالك سيبدو مثل:

font-size : @fontsize-body/number(@fontsize-heading) * 1em

لكنني موافق أيضًا على اقتراح @ seven-stage-max. لا يزال بإمكاننا تقييم _vars_ في calc() ، لكن ليس في الرياضيات. ولا تقيم القسمة خارج الأقواس. أعتقد أنه حل وسط جيد. وربما ، إذا أردت الحفاظ على رياضيات القسمة السحرية لتقسيم الوحدة على وحدة مع الاحتفاظ بالوحدة (التي لا تزال غريبة ، ولكن هذا جيد) ، فقد يحدث ذلك داخل الأقواس.

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

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

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

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

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

أود أيضًا أن أضيف أنني أعارض بشدة أي عمليات تخمين "للوحدات المتوافقة" (مثل دع a/b يبقى قسمًا و b/c لن يكون كذلك) في هذا السياق بالذات.
ببساطة لأن:

• المعالجة الاستثنائية هي أصل كل الشرور (على سبيل المثال # 3047 - انظر أدناه ، http://stackoverflow.com/questions/19705791- أذكر أنني لم أتمكن من العثور على سبب مشكلة SO حتى خطوت بالفعل من خلال كل من خطوط zillion من التعليمات البرمجية الأقل المضمنة في مصحح الأخطاء).
• والأهم من ذلك ، أنه ليس دليلًا على المستقبل ، بمعنى أنه إذا كان لا مفر من حدوث تغيير كبير ، فمن الأفضل أن نتأكد من إجرائه مرة واحدة (والأفضل للأبد) ... وليس كأنهم يضيفون بعض ميزات CSS الجديدة التي تتضمن a/b وانكسر مرة أخرى.

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

(خارج الموضوع:)
وبالمناسبة ، تحدثنا عن الأمثلة المذكورة أعلاه:
rjgotten إذا كان لديك:

@fontsize-body/@fontsize-heading * 1em; 

في مكان ما في الكود الخاص بك وأي من المتغيرين هو px أنت تستخدم بالفعل خطأ :)
الكود الصحيح هو:

1em * @fontsize-body/@fontsize-heading;

ينتج عن هذا دائمًا وحدة محددة جيدًا لكل http://lesscss.org/features/#features -overview-feature-Operations (بحساب # 3047 ليتم إصلاحها ، يكون الخطأ مرة أخرى مثالًا لخلل تم إنتاجه بالضبط بواسطة عدد كبير جدًا رمز التخمين حول "الوحدات المتوافقة" في قاعدة التعليمات البرمجية). لا حاجة حقيقية لـ --su ، number ، unit bla-bla ... السلوك الحالي -su مثل "ألقى خطأ فقط إذا رأيت وحدات غير متوافقة" ، أي التحقق البسيط ، هو أكثر من جيد (بالنسبة لي). لا أستطيع أن أرى أي حاجة لـ 1px/2px->.5 و 1px*2px->2px^2 للهندسة الزائدة من mambo-jambo. لكن مرة أخرى هذه قصة أخرى غير ذات صلة).

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

في الواقع باستخدام خطأ

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

أود أيضًا أن أضيف أنني أعارض بشدة أي عمليات تخمين "للوحدات المتوافقة" (مثل السماح لـ a / b أن تكون قسمة و b / c ليست كذلك) في هذا السياق المحدد.

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

أيضًا ، أدركت لاحقًا أن font: 10px/3 هو اختصار صالح. لذلك لا يوجد حل حسابي يمكن أن يساعد في ذلك.

للرجوع إلى سؤالك ،rjgotten ...

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

فكرة / علاقة Less to CSS تشبه TypeScript إلى JavaScript. أي ، قم بإعادة تسمية .css الخاص بك إلى .less ويمكنك البدء في إضافة ميزات أقل. على غرار الطريقة التي يمكنك بها إعادة تسمية .js إلى .ts والبدء في إضافة ميزات TypeScript. إذا لم تقم بإضافة أي شيء ، فيجب أن تحصل على نفس المخرجات الصالحة Less / JavaScript ، لأن اللغات هي مجموعات فرعية من اللغة الأساسية.

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

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

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

الذي - التي.

يعرف LESS أين يُسمح باستخدام / وأين لا يكون في css. في حالة عدم وجودها ولكن تظهر على أي حال ، يجب أن تفترض أن الرياضيات يجب إجراؤها. أيضًا عندما تكون الرياضيات محاطة بأقواس دائرية ، يجب تفسير الأقواس المستديرة باستخدام LESS.

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

thany

الكثير من الافتراضات لما يعرفه المترجم (وبعضها خاطئ ببساطة).
في كلتا الحالتين ، يكون وضع "الأقواس المستديرة" تقريبًا ما يفعله --sm=on ، لذا استخدم ذلك وتجاهل هذا الموضوع (على الأرجح أنك لا تستخدم أي رياضيات في مشاريعك بجانب calc (قدم القليل سنوات بعد تصميم Less) لذلك لا يمكنك رؤية مدى إزعاج الأقواس الزائدة. لكن الآخرين يفعلون ذلك.)

للبقية انظر https://github.com/less/less.js/issues/1880#issuecomment -345194431.

@ Seven-stage-max لا تنس أن / له أيضًا معنى في اختصارات background و border-radius ، وربما البعض الآخر الذي لا أفكر فيه الآن. سوف يعامل LESS هؤلاء بسعادة على أنهم قسمة. مع وضع الرياضيات الصارم أو بدونه ، يجب على LESS "معرفة متى تتوقف" عن إجراء العمليات الحسابية الصغيرة الخاصة بها.

thany
يجب على LESS "معرفة متى تتوقف" عن إجراء العمليات الحسابية الصغيرة الخاصة بها.

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

Sofar هناك خياران عاقلان ويمكن التنبؤ بهما لـ / كمشغل قسم:

• تعامل معه دائمًا على هذا النحو واطلب الهروب الصريح لاستخدامات أخرى.
  سيؤدي هذا إلى كسر السلوك حيث تكون البنية الأقل عبارة عن مجموعة شاملة صارمة من بناء جملة CSS.
• لا تعاملها أبدًا على أنها عامل قسمة ، __ إلا إذا كانت ضمن سياق رياضي معروف.
  أين يمكن / يمكن تحديد سياق الرياضيات المعروف كما في السلوك الحالي --strict-math=on .

_{(أيضًا ؛ يرجى ملاحظة أن الاسم الأقل لم يعد مكتوبًا بأحرف كبيرة.)}

لا تنس أن / لها أيضًا معنى في اختصارات الخلفية ونصف قطر الحدود ،

هذا هو الأساس الذي يبدأ به هذا الموضوع.
وانظر ملخص التغييرات المقترحة على https://github.com/less/less.js/issues/1880#issuecomment -345194431 (بدون أي افتراضات لما يجب أو لا يجب أن يعرفه المترجم).

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

وأنا أتفق مع هذا تماما. thany بينما كنت تتفق معي في ما نقلته عما كتبته ، فأنت توصل إلى نتيجة مختلفة عما كنت

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

لا تعاملها أبدًا على أنها عامل قسمة ، إلا إذا كانت ضمن سياق رياضي معروف.
حيث يمكن / سيتم تحديد سياق الرياضيات المعروف كما هو الحال في --strict-Math = على السلوك.

فقط للتوضيح ، هذا الجزء (الذي أوافق عليه):

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

يوجد في الواقع 4 حلول ممكنة ، أعلم أنك تعرفها ، لكن فقط أعد تلخيص الموضوع:

1. قم بإجراء كل الرياضيات فقط بين قوسين . يبدو أنه تم رفض هذا من قبل المشاعات ، وهو أمر جيد ، على الرغم من أنه لا يزال متاحًا كبديل اختياري ( strictMath ).
2. قم بإجراء كل الرياضيات في كل مكان ، ولكن القسمة بين قوسين فقط.
3. قم بإجراء كل الرياضيات في كل مكان ، ولكن القسمة بين قوسين فقط. ما لم تتم طباعة عامل القسمة كـ ./
4. قم بإجراء جميع الرياضيات في كل مكان ، ولكن أصلح الرياضيات بحيث لا يؤدي 12px/4px إلى القسمة. (الضرب والقسمة فقط بقيم أقل من وحدة). وبعبارة أخرى ، القسمة في كل مكان ، ولكن بقواعد أكثر تحفظًا. في الحالات التي لا تحل فيها الأمور ، ارجع إلى الهروب. لذلك ، ليس حلاً كاملاً ، لكنه لا يزال تحسينًا (قابلًا للجدل) للوضع الحالي.

من منظور قابلية الاستخدام ، أحب جعل الرياضيات "أكثر ذكاءً" كما في #4 . من وجهة نظر الهندسة والصيانة ، وللحماية من تغييرات CSS المستقبلية ، أحب #3 كحل أقوى.

ومع ذلك ، أعتقد في الواقع ، أننا سنحتاج إلى القيام بكل من #3 و #4 لإصلاح calc() . في الوقت الحالي ، يعد تجاهل كل الوحدات أقل عند إجراء الرياضيات يمثل فوضى حقيقية. لا ينبغي أبدًا لمس 100vh - 12px بأقل من (أقواس أم لا). لكن لا ينبغي أن يكون IMO 12px/4px (بين قوسين أم لا) ، لكن قد أكون أقلية في ذلك.

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

الضرب والقسمة فقط بقيم أقل من وحدة.

لن تؤدي الحيلة نظرًا لوجود أشياء مثل:

font: small-caps bold 24px/3 ...;
lost-column: 1/3;
// etc.

وهم ليسوا divs.

ومع ذلك ، أعتقد في الواقع ، أننا سنحتاج إلى القيام بكل من #3 و #4 لإصلاح calc()

calc() هو ألم. ومن المفارقات أنه من الأفضل حلها من خلال تنفيذها كدالة أقل فعلية ، والتي من شأنها أن تأخذ بشكل مثالي شجرة التعبير التي تم تحليلها وتحاول تبسيط التعبير. أي: يجب أن يحسب مسبقًا ويدمج المكونات المتوافقة مثل 4px + 12px (أو 4px + @a عندما يُعرف أن @a يحتوي على قيمة بكسل) مع ترك مكونات غير متوافقة ، على سبيل المثال تلك مع وحدات غير متوافقة ، وحدها.

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

<strong i="17">@a</strong> : 4px;
<strong i="18">@b</strong> : 2;
width : calc(100%/<strong i="19">@b</strong> - 10px + @a);

يجب أن تقدم في نهاية المطاف

width : calc(50% - 6px);

(أكرر نفسي من https://github.com/less/less.js/issues/1880#issuecomment-345345735)
ولا أرى أي فائدة من المبالغة في التفكير في المترجم من أجل تحسين التعبيرات داخل calc . إذا كنت تكتب calc فأنت على ما يرام مع المتصفح للقيام بالمهمة مهما كان التعبير الطويل لديك هناك. لذلك كما ذكرنا سابقًا ، أنا مع "عدم لمس أي شيء داخل calc " (= لا تحاول أن تكون أكثر ذكاءً مما هو ضروري حقًا) واتركه للمتصفح ( أو لمُصغر css منذ ذلك الحين ، إذا كنت أتذكر بشكل صحيح ، فإن البعض منهم يقوم بعمل جيد بالفعل في تحسين التعبيرات الفرعية للحساب).

يذكرني "سلوك الوحدة الذكية mamabo-jambo" بالوحوش min/max (كومة منتفخة من التعليمات البرمجية غير القابلة للصيانة والتي لم يتم استخدامها مطلقًا ) - إلى أي مدى يؤسفني أنني لم أصرخ ضد "وحدات mambo" في ذلك الوقت ، أوه (لذا سأستمر في التذمر هنا حتى يتم القضاء تمامًا على فكرة "دلالات المشغل المختلفة اعتمادًا على وحدات المعامل": P).

ملاحظة: بمجرد أن يصبح calc وظيفة تتلقى تعبيرًا غير مُقيَّم بحساب (سيتعين عليه على أي حال) ، سيتمكن المرء من كتابة مكون إضافي وتجاوزه بأي تحسين يرغب فيه.

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

أعتقد أنه نهج صحيح بشكل أساسي. LESS هو مترجم لـ CSS ، لذلك فمن المنطقي في العالم أن LESS يعرف ما الذي يقوم بالترجمة إليه.

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

من المثير للاهتمام التفكير في الأمر من الجانب الآخر ، إذا جاز التعبير. هذا ما أقترحه:

background: url(...) no-repeat 50% 50% / 40px + 10px 40px;

ما يجب فعله أقل هنا ، واضح لي:

background: url(...) no-repeat 50% 50% / (40px + 10px) 40px;

مما أدى إلى:

background: url(...) no-repeat 50% 50% / 50px 40px;

لا ينبغي أن يحسب الجزء 50% / 50px في هذا ، لأنه (1) لا ينبغي أن يكون قادرًا على ذلك بسبب الوحدات غير المتوافقة و (2) لأن هذا بالفعل بعيد بما يكفي لقيمة background . لذلك هذا هو المكان الذي "ستتوقف فيه عن حل الرياضيات".

هذا ما قصدته بعبارة "معرفة متى تتوقف".

هل كانت خاصية مختلفة مثل هذا:

padding-left: 50% / 10px + 5px;

يجب أن ينكسر بسبب خطأ (وحدات غير متوافقة). سيكون أحد المخرجات المحتملة 50% / 15px وهو غير صالح لهذه الخاصية. قد تكون النتيجة الأخرى هي 5% وهو ما ستفعله حاليًا ، وهو خطأ في كل اتجاه.
و:

padding-left: 50px / 10px + 5px;

يجب أن ينتج عنه:

padding-left: 10px;

كما هو متوقع. لذا في هذه الحالة ، فإن / غير صالح لـ padding-left ويتم أخذها في LESS وتقوم بعمل الرياضيات الخاصة بها.

@ ماثيو دين
يوجد في الواقع 4 حلول ممكنة ، أعلم أنك تعرفها ، لكن فقط أعد تلخيص الموضوع:

مرة اخرى:
5) استخدم عامل التشغيل \ للأقسام في LESS ، وقم بإيقافها باستخدام / . يحتوي MATLAB على شيء من هذا القبيل ، وقد استخدمته بعض نكهات BASIC لفرض القسمة الصحيحة. لذا فإن استخدام الشرطة المائلة للخلف لم يسمع به من قبل.

/تعديل
يمكننا أيضًا الضغط لتضمين مفتاح ÷ على keybaords واستخدامه كمشغل للقسم. هذا هو ما تعلمته في المدرسة الابتدائية :)

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

استخدم عامل التشغيل \ للأقسام في LESS ، وقم بإيقاف العمل باستخدام / .

https://github.com/less/less.js/issues/1872#issuecomment -35245890

يكفي لـ background ... غير صالح لـ padding-left

تعرف على "الرجال ، متصفحي / polyfill / أيًا كان ما أضاف / تحديث / دعمًا موسعًا لخاصية fnord ، هل يمكنك إطلاق إصدار Less جديد من أجلي؟" القضية.
تعرف على مشكلة font .
إلخ.
حسنًا ، علّق rjgotten بالفعل أعلاه على سبب كون هذا النوع من "المعرفة" هو الطريق إلى اللامكان.

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

تعرف على "الرجال ، متصفحي / polyfill / أيًا ما تمت إضافته / تحديثه / توسيع دعمه لخاصية fnord ، هل يمكنك إطلاق إصدار أقل لي من فضلك؟" القضية.

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

واجه مشكلة الخط.

تثبت مشكلة الخط أن مشكلة / كانت موجودة منذ البدايات المطلقة لـ LESS. ليس فقط عندما يكون لدى background القدرة على تضمين قيمة لحجم الخلفية أو عندما يظهر border-radius . Tbh ، من خلال ذكر مشكلة الخط ، تكون قد قدمت للتو أفضل حجة ضد نفسك :)

Tbh ، من خلال ذكر مشكلة الخط ، تكون قد قدمت للتو أفضل حجة ضد نفسك :)

أعتقد أنك تسيء فهم شيء ما. كنت أنا من اقترح في البداية إزالة / تمامًا كمعامل div. لذلك بالنسبة لبقية الأشياء ، أفترض أنها نفس المشكلة المتمثلة في عدم اهتمامك بما يتم الرد عليه.

CSS هو معيار محدد جيدًا.

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

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

لن تقوم بالخدعة نظرًا لوجود أشياء مثل: الخط: الأحرف الكبيرة الصغيرة الغامقة 24 بكسل / 3 ...

لا ، فهمت. كانت وجهة نظري هي أن: div / الضرب بدون وحدة فقط يقلل من المشكلة ولكنه لا يحل المشكلة.

وأعتقد بشكل عام أن اقتراحك بـ ./ لجميع الأقسام لا يزال منطقيًا تمامًا.

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

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

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

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

thany

تثبت مشكلة الخط أن المشكلة / كانت موجودة منذ البدايات المطلقة لـ LESS.

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

بالمناسبة ، هذه هي الطريقة التي يحل بها Sass المشكلة ، موضحًا في هذا المثال:

p {
  font: 10px/8px;             // Plain CSS, no division
  $width: 1000px;
  width: $width/2;            // Uses a variable, does division
  width: round(1.5)/2;        // Uses a function, does division
  height: (500px/2);          // Uses parentheses, does division
  margin-left: 5px + 8px/2px; // Uses +, does division
  font: (italic bold 10px/8px); // In a list, parentheses don't count
}

إنه ليس واحد لواحد ، حيث يمكنك القيام بالرياضيات (حاليًا) ضمن وسيطات لوظائف أقل ، ويمكن للدوال الأقل أن ترجع قيم البكسل (لذا يمكن أن تقوم أقل بـ font: print10px()/8px ، من الناحية النظرية؟ لا؟) ، لذلك أنا أنا فقط ألصقه بشكل توضيحي ، وليس كأي نوع من الاقتراحات. من المثير للاهتمام كيف تعاملوا مع المشكلة.

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

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

+1

_{حتى مع عدم احتساب أن "الحل" لا يحل lessc --sm بالفعل. ونتائج مختلفة لـ 1/2 و $var/2 هي مجرد رائعة بشكل استثنائي ... ~ غباء ~ "تصحيح أخطاء سعيد ، أيها الخاسر!"}

@ ماثيو دين
بالمناسبة ، هذه هي الطريقة التي يحل بها Sass المشكلة ، موضحًا في هذا المثال:

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

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

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

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

ولا نأخذ في الحسبان أن "الحل" لا يحل أيًا من المشكلات التي نوقشت هنا بخلاف ما يفعله أقل من SM بالفعل. لماذا سأكتب 0 + 1/2 بدلاً من (1/2) بينما ما أريده هو مجرد قسمة؟ والنتائج المختلفة لـ 1/2 و $ var / 2 هي مجرد نتائج رائعة بشكل مذهل ... غباء "تصحيح أخطاء سعيد ، أيها الخاسرون!" رسالة.

ها ، نعم ، هذا.

thany

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

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

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

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

ما زلت تتجادل مع خيالك وليس مع ما يخبرونك به. أجب عن السؤال البسيط: "كيف يمكن أن يكون 0 + 1/2 أفضل من (1/2) ؟". إذا كان التوافق بنسبة 100٪ مع CSS هو الشيء الوحيد الذي تهتم به ، فقم بتعيين -sm الجميل وتنسى أمر هذا الموضوع.

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

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

سأكون على استعداد لإجراء هذه التغييرات العاجلة كأولوية:

1. تتطلب الرياضيات خارج الأقواس ./ بدلاً من / عارية. لا يزال يبدو 12px./10px غريبًا بعض الشيء.

@ Seven-stage-max - أريد إعادة زيارة الشرطة المائلة للخلف. فيما يتعلق بهذا ، أعلم أنك ذكرت https://github.com/less/less.js/issues/1872#issuecomment -35245890 ، لكنني لا أرى أي تعارض صريح ، لأن هذه المعرفات ليست كذلك وأعتقد أنه لا يمكن جزء من التعبيرات الرياضية. أو انا مخطئ؟ أفترض أنه من الممكن التوصل إلى حالة نظرية مثل اسم وظيفة مع شخصية هاربة كجزء من الاسم ، لكن هذا يبدو وكأنه تمرين فكري أكثر منه حالة واقعية. المحددات المتسربة ، نعم ، هذه تُستخدم بشكل شائع لأسباب مختلفة ، ولكن في قيم الملكية ، يبدو من غير المحتمل ، أو ، في حالة الحافة ، لا بأس في كسر / حل بديل للحل التاريخي (فقط الهروب من هذا النص).

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

1. (الأولوية الثانية) يكون calc() بغلاف خاص بحيث يمكنه إجراء استبدال متغير ولكن لن يقيم أي تعبيرات رياضية

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

حسنًا ، مشكلة أن \anycharacter هي CSS صالحة ولها معنى خاص بها. بالتأكيد ، بالكاد تجد مثل هذا الرمز في المشاريع الحقيقية (باستثناء ربما الاختراقات مثل \9 مثل الاختراقات) ، لكن ... هل نريد إطعام هذا الأسد؟ إصلاح أحد "uh-oh ، لا يتم ترجمة CSS الصالحة بنسبة 100٪" من خلال تقديم "uh-oh" آخر من نفس الأصوات غريبًا بعض الشيء :)

بالنسبة إلى calc أعتقد أننا حصلنا على إجماع منذ البداية - لذلك في الأساس لا ينتظر سوى متطوع لتنفيذه (أقدر أن الإصلاح السريع يجب أن يتم في 5-6 أسطر فقط من الكود الجديد - لذلك إن الأمر يتعلق فقط برجل شجاع للقيام بذلك - قد تختلف تفاصيل التنفيذ الطفيفة لكنني أعتقد أنه من الجيد أن يتم تحديدها في العملية).

حسنًا ، المشكلة التي مفادها أن \ anycharacter هي CSS صالحة ولها معنى خاص بها. بالتأكيد ، بالكاد تجد مثل هذا الرمز في المشاريع الحقيقية (باستثناء ربما الاختراقات التي تشبه 9) ، لكن ... هل نريد إطعام هذا الأسد؟ إصلاح أحد "uh-oh ، لا يتم ترجمة CSS الصالحة بنسبة 100٪" من خلال تقديم "uh-oh" آخر من نفس الأصوات غريبًا بعض الشيء :)

أسمعك ، إنها مقايضة محتملة. ونعم أعلم أن \anycharacter هو CSS صالح. أعتقد أنني أتساءل عما إذا كانت مجموعة أفضل من المقايضات. إنه فقط عندما كتبت 12px./10px شعرت بالغرابة ، من الناحية التركيبية. أشعر أن Less من الناحية التركيبية حاولت إعادة استخدام CSS قدر الإمكان دون خلق تعارضات.

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

بالنسبة للحساب ، أعتقد أننا حصلنا على إجماع منذ البداية - لذلك في الأساس ينتظر فقط متطوع لتنفيذه (أقدر أن الإصلاح السريع يجب أن يتم في 5-6 أسطر فقط من الكود الجديد - لذلك فهو في الحقيقة يتعلق فقط بـ رجل شجاع للقيام بذلك - قد تختلف تفاصيل التنفيذ البسيطة ، لكنني أعتقد أنه لا بأس من أن يتم تحديدها في العملية).

حسن! هل يجب أن نتتبعه بشكل منفصل لزيادة الرؤية؟

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

بالتأكيد ، بالكاد تجد مثل هذا الرمز في المشاريع الحقيقية (باستثناء ربما الاختراقات مثل \9 مثل الاختراقات)

حق . يا هذا "الغربيون" المتغطرسون ... :)

@ سبع مراحل كحد أقصى
أجب عن السؤال البسيط: "كيف يمكن أن تكون 0 + 1/2 أفضل من (1/2)؟"

لا أرى إلى أين أنت ذاهب مع ذلك. يجب أن يتم تنفيذ (1/2) بواسطة LESS لأنه لا يمكن أن يكون CSS صالحًا ، لذلك يجب أن يُقصد به على أنه LESS. يجب أن يصبح 0 + 1/2 1/2 حيث ينفذ LESS الجزء 0 + 1 لأن هذا هو الجزء الذي لا يمكن أن يكون CSS صالحًا. قد يكون الجزء 1/2 صالحًا ، لذا من الأفضل عدم لمسه.

thany
حسنًا ، أدرك الآن أن (1/2) يعمل بالشكل الذي تتوقعه في كل من Less و Sass ..
و 0 + 1/2 (بالإضافة إلى 1 * 1/2 وما إلى ذلك) هو جزء من الحل الذي تسميه رائعًا أعلاه وقرار "الحل الرائع" هو 0.5 .
لا يزال لا يوجد دليل على ما يحدث هنا؟
أعد قراءة كل شيء (بدءًا من أول مشاركة لك) أعلاه مرة أخرى وحاول الإجابة على نفسك "ما الذي أشكو منه بالضبط ؟".

@ سبع مراحل كحد أقصى
و 0 + 1/2 (بالإضافة إلى 1 * 1/2 وما إلى ذلك) هو جزء من الحل الذي تسميه الرائع أعلاه وقرار "الحل الرائع" هو 0.5.

لا ، سيكون الحل هو 1/2 وليس 0.5 ، نظرًا لأن 1/2 قد يكون CSS صالحًا. يبدو أنك لا تريد أن يعرف LESS متى تكون الشرطة المائلة صالحة ، لذا افترض أنها قد تكون كذلك دائمًا. لذلك فإن 1/2 هو النتيجة المنطقية الوحيدة. بنفس الطريقة ، فإن 2 * 1/2 سينتج عنه 2/2 ، لأن * سيجعله CSS غير صالح.

لا يزال لا يوجد دليل على ما يحدث هنا؟

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

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

ليست هناك حاجة للهجمات الشخصية.

ينفذ LESS أقسام الرياضيات بفارغ الصبر ويتجاهل الوحدات بشكل أعمى.

إذن هذا ما تشكو منه ، أليس كذلك؟

ليست هناك حاجة للهجمات الشخصية.

إذن ماذا علي أن أفعل بدلاً من ذلك؟ هل تريد تكرار المنشورين الأصليين مرارًا وتكرارًا (ومرة أخرى)؟ حتى يتضح لك:
@ مجتمع :

استخدم الخيار -sm

thany :

ثم يجب أن يكون في وضع التشغيل بشكل افتراضي.

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

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

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

إذن ما هذا الموضوع هو حول؟ يتعلق الأمر "بإدراك أنه في حين أن تغييرًا نهائيًا في إجراء" -sm يشبه السلوك الافتراضي أمر لا مفر منه ، يتعين علينا توفير تسهيلات لعملية حسابية أكثر راحة بخلاف المخيف: margin: (1/2) (3/4) (5/6) (7/8); لأولئك الذين استخدم الحساب كثيرًا ".
تنشر هنا إما أن تقترح شيئًا ليس أفضل من (أو تفعل الشيء نفسه تمامًا) الموجود بالفعل -sm السلوك أو تجادل مع شيء غير وارد منذ البداية (مثل هناك ). بعبارة أخرى ، مجرد ضوضاء عشوائية .

@ سبع مراحل كحد أقصى hany دعونا قليلاً . هناك آراء قوية في كل مكان.

أعتقد أن معظم الأشخاص يتواجدون في نفس الصفحة حول كلا هذين الأمرين بشكل مثالي لا يتم تفسيرهما بواسطة Less كتعبير رياضي:

font: 12px/10px;
width: calc(100% - 20px);

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

أصبحت الحلول الخاصة بالجزء font أكثر شعرًا وكانت الحلول الرائدة هي:

1. طلب أقواس لكل شيء افتراضيًا (المحاولة الأولى - تم تنفيذها تقريبًا ، لكن المجتمع رفض)
2. اقلب المفتاح strictMath (الذي تمت إضافته بدلاً من جعله الافتراضي ، واقتراح @ seven-stage-max) ثم قم بكل ما تريده بشكل صريح. إنه ، من الناحية الفنية ، حل محتمل لمعظم الناس في الوقت الحاضر ، لكن ... السؤال يطرح كثيرًا ونعلم ، من الناحية النفسية ، أن شخصًا جديدًا في أي نظام من المحتمل أن يحتفظ بأي إعدادات افتراضية ، لذا فهي مشكلة. ولا يمكن لكل مطور تغيير إعدادات البناء ، خاصة في الفرق.
3. قم بتغيير عامل القسمة بشكل أساسي في أقل. كان المنافس الرائد في الموضوع هو ./ ، وهو أمر يعمل ولكن من الغريب بعض الشيء النظر إليه. \ غير معروف في هذه المرحلة بدون بحث. يمكن أن تعمل ، يمكن أن تسبب صراعات غير معروفة مع الهروب. إنها بنية أنظف ، مع مخاطر أعلى (محتملة ، لكنها غير معروفة). إذا أخذ شخص ما الوقت الكافي للتوضيح أن هذا لن يتسبب في حدوث نزاع ، أي تقديم أمثلة على الهروب والرياضيات المختلطة بطريقة يمكن للمحلل التمييز بينها بوضوح ، فلا يزال هذا احتمالًا. لذا فإن الأمر يتطلب العمل فقط. thany ، إذا كنت أنت أو أي شخص آخر معجب بهذا ، فهذا هو العمل المطلوب. آخر شيء نريده هو نقل الفواصل إلى مكان آخر.

أعتقد ، لتبسيط هذا الموضوع ، يجب علينا ، من هنا ، التركيز فقط على #3 . لقد نشرت مثال Sass غالبًا بدافع الفضول ، لكنني لا أعتقد أن هذه الحلول جيدة أو تحل المشكلة تمامًا ، وهي غير متوافقة من الناحية المفاهيمية مع Less. الجدال حول صلاحية طلب 0 + 1/2 لن يقودنا إلى أي مكان.

لذلك ، مع وجود حل جيد على الطاولة مقابل calc() ، والذي يمنحنا 50٪ من الطريق إلى هناك لمعظم المشكلات المنشورة ، أوصي بالتركيز فقط على هذا السؤال على المدى القصير:

إذا كان يجب تغيير عامل القسمة الأقل ، فما الذي يجب تغييره إليه؟

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

بصراحة ، إذا قمنا بتغيير calc() وقمنا بتغيير / ، أعتقد أننا سنهدأ 99٪ من الضوضاء حول الرياضيات في أقل.

مرحبًا ، لقد أصلحت calc() - https://github.com/less/less.js/pull/3162

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

تحقق من https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d و https://github.com/less/less.js/pull/3162/files#diff -4e696271823c96903a91fff84983bab6

هل الاختبارات كافية؟

@ ماثيو دين: القهوة:

هل الاختبارات كافية؟

لكل تعليق في العلاقات العامة ، يرجى إضافة اختبار مثل:

foo: 1 + 2 calc(3 + 4) 5 + 6; // expected result: 3 calc(3 + 4) 11;

وملاحظة بسيطة: من الواضح أن هذا الإصلاح يقدم نفس المشكلة كما في # 1627 ، أي

<strong i="13">@a</strong>: floor(1.1);
<strong i="14">@b</strong>: floor(1 + .1);

div {
    foo: calc(<strong i="15">@a</strong> + 20%); // ok
    bar: calc(<strong i="16">@b</strong> + 20%); // error: invalid floor arguments
    baz: @b;             // ok
}

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

وملاحظة بسيطة: من الواضح أن هذا الإصلاح يقدم نفس المشكلة كما في # 1627

مسكة جيدة!

تبديل السياق mathOn property لكل مكالمة يحل هذا الأمر ، على غرار تعليقك في PR. لقد أضفت اختبارًا لـ float(1 + .1) والذي نجح!

يؤدي تبديل خاصية mathOn الخاصة بالسياق لكل مكالمة إلى حل هذا الأمر ، على غرار تعليقك في PR. لقد> أضفت اختبار تعويم (1 + .1) والذي ينجح!

:) لا ، يجب أن يظهر خطأ "الأرضية" عندما يكون -sm: off . انظر تعليقي الأحدث في العلاقات العامة.
لا تهتم عملية الاستعادة إلا بـ 1 + 2 calc(3 + 4) 5 + 6 مثل الأشياء.

:) لا ، يجب أن يكون الخطأ "floor" موجودًا عند -sm: off.

لماذا ا؟ يجب أن تكون أي وظائف داخل calc() وظائف أقل. حتى لو لم تكن كذلك ، فلا توجد دوال CSS أصلية داخل calc () أدرك أنها يمكن أن تأخذ تعبيرات رياضية أولية. ستكون النتيجة المتوقعة هي تقييم دالات vars و Less ، مع ترك الدوال الأولية داخل calc() بمفردها.

ملاحظة جانبية: لقد أجريت تجربة فرع للتبديل بين / إلى \ كمعامل قسمة في Less. يوجد بالفعل الكثير من الاختبارات للهروب (وأضفت المزيد ، إلى العنوان: # 3160) ، وما زالوا جميعًا يعملون بشكل جيد ، والرياضيات تعمل بشكل جيد مع تبديل المشغلين. لم أر أي صراع متأصل. الفرع هنا على مفترقتي: https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

إعادة: الوظائف المتداخلة

من أجل هذا:

div {
    bar: calc(floor(1 + .1) + 20%);
}

كمطور ، يجب أن تكون النتيجة المتوقعة:

div {
    bar: calc(1 + 20%);
}

هذا بالضبط ما يحدث الآن (مع هذه التغييرات). لا ينبغي أن يلقي خطأ.

@ ماثيو دين
لا ، بالطريقة التي كتبتها ، هذا:

foo: unit(1/2, px);

باستخدام -sm:on سيتم التحويل البرمجي إلى:

foo: .5px;

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

foo: floor(1 + .1);
bar: calc(floor(1 + .1) + 20%);`

يجب أن يخطئ (وهذا ما ينكسر في الالتزام).

عن ماذا تتحدث؟

unit(1/2, px) مع -sm:on :

ERROR: error evaluating function `unit`: the first argument to unit must be a number. Have you forgotten parenthesis?

calc(floor(1 + .1) + 20%) مع -sm:on

ERROR: error evaluating function `floor`: argument must be a number

تحقق من الفرع. حاول.

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

اعتذر. أعتقد أنني فاتني التحكم غير المباشر في هذا الجزء .

تحقق من الفرع. حاول

لا أستطيع ، آسف.

اعتذر. أعتقد أنني فقدت السيطرة غير المباشرة لهذا الجزء.

لا قلق. مع ذلك ، هل يبدو أنه يعمل كما تتوقع؟

مع ذلك ، هل يبدو أنه يعمل كما تتوقع؟

نعم ، حتى الآن لا يمكنني تخيل أي أشياء أخرى مشبوهة هناك.

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

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

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

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

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

12px/10px  // Is this division, or not?
10px/1.5 // is this division, or not? 

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

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

font: 10px/1.5;   // not division
font: (10px/10);  // division, result is 1px
font: 10px+15px/1.5;   // addition but not division, result is 25px/1.5
font: (10px+15px/1.5);  // result is 20px

الشيء هو أن نتيجة 10px+15px/1.5 قد لا تزال صعبة على المطورين ، مع تعبير يبدو أنه حصل على "نصف تقييم" ما لم يكن بين قوسين. إذا كنا قد تقدمنا ​​وقمنا بتشغيل الرياضيات الصارمة بشكل افتراضي ، فمن المحتمل أن يكون الأمر جيدًا. إنها حتى أقل غموضًا. [shrug] في كلتا الحالتين ، فإن التفاف الرياضيات في نوع من السياق هو السبيل للقضاء على الغموض ، والطريقة الوحيدة للتقسيم بخلاف تغيير عامل القسمة.

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

آخر دعوة لاتخاذ قرار

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

امنح إعدادات --strict-math 3

1. إيقاف
2. قطاع
3. صارم (الاسم المستعار on للتوافق الخلفي)

لتسوية المناقشة ، اسمح للمحول --strict-math=division بالقيام بما يلي:

1. لا تقم بإجراء القسمة باستخدام حرف / خارج الأقواس. على سبيل المثال ، border-radius: 55px / 25px; -> no-math (نعم ، هذا CSS صالح)
2. اسمح بالقسمة بطريقتين مختلفتين:
   أ. البادئة . - border-radius: 55px ./ 25px;
   ب. أقواس - border-radius: (55px / 25px);
3. كلا النموذجين صالحين بين قوسين - على سبيل المثال border-radius: (55px ./ 25px); سيكون صالحًا

لذلك ، بصفتك مطورًا ، إذا شعرت أن أحد الإصدارات ليس هو ما تفضله ، فيمكنك استخدام الإصدار الآخر. قد يفضل البعض عدم استخدام الأقواس ؛ قد يفضل البعض عدم استخدام عامل تقسيم معدل. شيء للجميع. ولا مزيد من المفاجآت غير السارة لأولئك الجدد إلى أقل باستخدام ما هو الآن بناء جملة واسع الانتشار في CSS ، حيث يتم استخدام / في font ، background ، border-radius ، @media ، خصائص CSS Grid ، وربما أكثر في المستقبل.

الخطوات التالية

أوصي بأن ينتقل هذا إلى PR كخيار ، ثم ، كما تمت مناقشته ، يتم تبديله كخيار افتراضي لإصدار رئيسي مستقبلي

@ ماثيو دين

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

وكل الأشياء التي تم أخذها في الاعتبار ، ربما تكون من أنظف الحلول الممكنة.

rjgotten بدأت هنا: https://github.com/matthew-dean/less.js/tree/strict-math-division

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

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

1. معالجة القسمة وميزة strictMath: 'division' .
2. التعامل مع رياضيات الوحدات المختلطة. انظر: https://github.com/less/less.js/issues/3047