Less.js: Bagaimana menangani Matematika

Saya tidak berpikir kami ingin mengubah banyak hal atau kembali ke papan gambar

Ya, saya menyarankan untuk memulai ini hanya karena _if_ kita menginginkan matematika ketat "default" di 3.0 kita harus menemukan sesuatu yang lebih ringan daripada yang sekarang (dan kemungkinan untuk memperbaiki semua masalah tanpa memperkenalkan --alt-strict-math Opsi font -seperti solusi hardcoding...).

Saya tidak menyadari bahwa itu tumbuh

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

:(

Saya pikir saat ini saya mendukung perluasan strictMaths menjadi

• Mati
• Divisi
• Pada

dan kemudian untuk 2.0.0 pengaturan default menjadi Divisi

Jadi..

Kueri Media - jika tidak aktif, alihkan ke divisi untuk sub node
Font - jika tidak aktif, alihkan ke divisi untuk sub node
calc( - jika mati atau pembagian, aktifkan untuk sub node

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

Ya, saya pikir mereka akan mengizinkan "nilai singkatan" (yaitu x/y ) di _any_ "properti shorhand"...

terkait: https://github.com/less/less.js/issues/1480

Pilihan lain .. proses panggilan kalk tetapi hanya jika unit memungkinkan misalnya
kalk( 1% + 2%) => 3%
calc(100% - 10 px) => tidak berubah

Ini akan memperbaiki calc tetapi tidak akan memperbaiki #1627 dan hal-hal terkait.
Maksud saya ya, calc(100% - 10 px) => unchanged bisa menjadi solusi untuk calc tetapi ini tidak membatalkan kebutuhan akan solusi less-heavy-than-parens-everywhere .

Jika matematika ketat sedang ditinjau kembali, saya ingin menyarankan bahwa Lebih sedikit fungsi seperti percentage() tidak memerlukan tanda kurung tambahan di dalamnya. Dengan matematika yang ketat, Anda harus melipatgandakan argumen. Ini akan sangat mengurangi kemungkinan kebingungan dan bug yang sulit ditemukan, karena percentage(16 / 17) dan percentage((16 / 17)) akan valid.

@calvinjuarez V2 menyediakan subsistem plugin di mana sebuah plugin dapat menambahkan sejumlah fungsi yang berubah-ubah ke lingkungan dan dalam hal ini inti tidak akan dapat memutuskan apakah fungsi bawaan tersebut mengharapkan nilai tunggal atau ekspresi, yaitu diizinkan untuk menerima 16/17 , dan kemudian mengevaluasi 16/17 _before_ dilewatkan ke suatu fungsi akan salah (yah, secara kasar - ini sedikit lebih rumit daripada itu secara internal).

Dalam konteks itu ./ change tampaknya menjadi favorit saya meskipun saya mengerti itu akan menjadi perubahan yang sangat dramatis (jika dibandingkan dengan (/) , tidak termasuk itu juga membutuhkan spasi sebelum . , misalnya 16 ./17 dan bukan 16./17 , hmm).

Hal lain di mana less saat ini merusak css yang valid adalah singkatan latar belakang:

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

Saya pikir saat ini saya mendukung perluasan strictMaths menjadi

Mati
Divisi
Pada
dan kemudian untuk 2.0.0 pengaturan default menjadi Divisi

Maaf saya tidak menanggapi ini sebelum 2.0 dirilis. Saya pikir itu insting yang bagus. Operator divisi telanjang hanya berkonflik dengan terlalu banyak CSS, dan akan semakin berkonflik karena orang menggunakan lebih banyak fitur CSS3. Dan saya memahami dorongan orang untuk tidak memerlukan orang tua untuk semua matematika, karena itu tidak diperlukan dalam banyak kasus.

@seven-fase-max

itu diizinkan untuk menerima 16/17, dan kemudian mengevaluasi 16/17 sebelum diteruskan ke suatu fungsi akan salah

Tegasnya, ya itu benar sekali. Ini tidak boleh dievaluasi SEBELUM mencapai fungsi, terutama untuk yang khusus. Namun, saya pikir akan bijaksana untuk mengizinkan fungsi memilih untuk memproses argumen seperti ini, jika masuk akal. Jadi, persentase akan menerima 16/17 sebagai argumen teks, dan kemudian fungsi persentase dapat melakukan panggilan ke beberapa fungsi pembantu untuk melihat apakah teks tersebut matematika. Dalam hal persentase, argumennya tidak ambigu. Deklarasi CSS3 tidak valid di sini. Jadi, fungsi yang ditentukan pengguna lainnya dapat beroperasi dengan cara yang sama: memilih untuk mengevaluasi argumen untuk persamaan matematika yang valid. Oleh karena itu, tidak selalu benar bahwa matematika ketat "memaksa" tanda kurung ganda dalam kasus ini. Saya pikir untuk menyarankan itu menyebabkan beberapa dorongan balik pada gagasan matematika ketat, bahwa itu harus, sebagai suatu keharusan, bertele-tele dalam semua kasus.

Opsi --math kami bisa lebih seperti:

• Selalu
• Divisi (bawaan)
• Ketat

Jadi, kita dapat menghentikan --strict-math=true dan menjadikannya alias untuk --math=strict

Namun, saya pikir akan bijaksana untuk mengizinkan fungsi memilih untuk memproses argumen seperti ini, jika masuk akal.

Mereka sudah diizinkan (cukup uji bagaimana percentage(16 / 17) dan percentage((16 / 17)) bekerja dengan --strict-math=on ).
Meskipun tidak ada fungsi yang menggunakan:

dan kemudian fungsi persentase dapat melakukan panggilan ke beberapa fungsi pembantu untuk melihat apakah teksnya matematika.

hanya karena dengan cara ini setiap fungsi harus memiliki ~20 baris ekstra dari extra-helpers-conversion-arg-checking-smart-arg-handling-stuff sementara kode fungsi sendiri hanya satu (!) baris dalam banyak kasus.

Setiap fungsi harus memiliki 20 baris tambahan? Bagaimana menurutmu?

Jika persentase sudah berfungsi dengan matematika ketat kurung tunggal, maka saya tidak mengerti masalah @calvinjuarez . Anda tampaknya menyiratkan dalam tanggapan Anda bahwa tanda kurung tunggal tidak dapat dicapai.

Setiap fungsi harus memiliki 20 baris tambahan? Bagaimana menurutmu?

Itu hanya berlebihan khas: mungkin 5, mungkin 10, mungkin 20... Siapa yang akan peduli dengan angka yang tepat jika rasio real-code/aux-code -> 0 . (Mengambil pendekatan pragmatis, saya akan berhenti di percentage(16 / 17) hanya membuat kesalahan alih-alih menghasilkan NaN% (seperti sekarang), dan tidak mencoba melakukan konversi apa pun ... Meskipun cara ini masih 4 baris kode tambahan - saya kira kurang atau lebih dapat diterima :)

Balasan awal saya menyiratkan bahwa dia menganggap konversi 16/17 -> (16/17) dilakukan secara implisit oleh kompiler itu sendiri (dan bukan oleh fungsinya).

Berbicara tentang pilihan. Di dunia yang sempurna saya akan bermimpi tidak ada opsi untuk ini sama sekali (yaitu itu harus menjadi satu-satunya dan sisanya ditandai sebagai usang dan akhirnya dihapus)... Semua opsi tambahan ini membuat basis kode tidak -maintainable.. bahkan untuk one-liner kecil memperbaiki/mengubah jumlah kasus tepi yang harus Anda prediksi dan tes yang perlu Anda lakukan tumbuh secara eksponensial... (hampir tanpa alasan).

Saya hanya berpikir itu akan menjadi sesuatu seperti:

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

Berbicara tentang pilihan. Di dunia yang sempurna saya akan bermimpi tidak ada pilihan untuk ini sama sekali

Saya setuju. Tapi kita akan membutuhkan pilihan dalam jangka pendek. Terutama jika kita menyimpang dari matematika yang ketat dan perilaku warisan. Keduanya dapat ditandai sebagai usang jika kita menyempurnakan opsi "matematika yang lebih cerdas".

Helper.convertMath(arguments);

arguments terlalu optimis.
Paling-paling (menghitung bukan hanya percentage - yang bagaimanapun juga tidak berguna , tetapi fungsi lain apa pun yang mengharapkan argumen numerik) persyaratan minimal adalah:

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

Tapi itu bukan maksud saya sebenarnya, yang saya maksud mungkin adalah sesuatu seperti: sementara ini selalu/mungkin, tidak ada yang mau repot-repot menulis kode seperti itu... (dengan beberapa pengecualian terbatas seperti )...

Ya, saya mengerti Anda.

percentage(16 / 17) baru saja membuat kesalahan

akan menjadi perbaikan, tentu saja. (Saya tidak dapat memikirkan kapan NaN% akan menjadi keluaran yang berguna.)

Sejauh fungsi mana yang akan mencoba menjadi pintar tentang argumen mereka, tidak ada alasan untuk mencoba mengantisipasi semuanya. Fungsi pembantu seperti yang disarankan @matthew-dean dapat diimplementasikan dengan cukup sederhana karena permintaan fitur dibuat dan didiskusikan untuk fungsi tertentu menjadi lebih pintar.

Sebenarnya, sejak awal, saya akan mengatakan bahwa hanya fungsi matematika yang harus pintar tentang argumennya.

Sunting: Sebenarnya, setiap kali fungsi matematika dilewatkan hanya satu argumen.

Ini statusnya apa? Kami menerima keluhan bahwa KURANG mencoba mengurai properti CSS yang tidak valid sebagai matematika. misalnya lost-column: 1/3; istirahat.

Tampaknya http://www.w3.org/TR/css-grid-1/#grid -template-rowcol tidak akan berfungsi dengan KURANG.

Bisakah seseorang menambal ini jadi jika seseorang secara eksplisit ingin menggunakan KURANG untuk melakukan pembagian pada properti yang mereka butuhkan untuk membungkusnya dengan parens atau sesuatu?

@corysimmons Bukankah Anda baru saja menanyakan ini di #2769 dan mendapatkan jawaban? o_O

Satu hal yang tidak kami diskusikan ketika ini pertama kali terjadi. Tampaknya satu-satunya konflik matematika yang sebenarnya adalah pembagian. Dan pembagian pada dasarnya adalah masalah karena pada dasarnya kita "mengganti" karakter "pemisahan" CSS.

Daripada mencoba untuk "membungkus" pembagian dengan berbagai cara, atau membungkus semua matematika (sebagai solusi pertama kami untuk masalah ini) saya bertanya-tanya mengapa kami tidak pernah berbicara tentang yang sudah jelas: _tidak menggunakan kembali operator yang ada_, terutama ketika itu sangat jelas a) membuat kode Kurang ambigu, b) menyebabkan konflik.

Setelah kita punya waktu untuk mencerna ini, membungkus matematika dalam tanda kurung, bahkan jika itu hanya pembagian, _still_ menyebabkan ambiguitas untuk kasus di mana matematika sudah dalam tanda kurung. (Yang juga bisa berarti bahwa tanda kurung adalah pilihan yang salah dari "pembungkus matematika".)

Jadi mengapa tidak menghentikan / sebagai operator divisi? Saya tahu bahwa ini adalah simbol pembagian yang umum, tetapi ada pertukaran sintaks lainnya yang dilakukan Less untuk memperluas CSS. Dan jelas bagi saya sekarang bahwa kita pada dasarnya mencoba untuk mengatasi masalah yang dibuat oleh Less sejak awal dengan menggunakan garis miring tunggal. Kami menciptakan ambiguitas, dan kemudian mencoba membalikkan ambiguitas tersebut.

Agar adil, simbol matematika lainnya semuanya digunakan kembali di bagian lain CSS, hanya saja penggunaannya dalam matematika tidak menyebabkan ambiguitas.

Saya akan mengusulkan beberapa ide, tetapi, lihatlah, sudah ada karakter alternatif standar untuk pembagian. Selain ÷ , yang tidak ada di keyboard, saya menemukan ini:

Tanda pembagian juga secara matematis setara dengan simbol rasio, biasanya dilambangkan dengan titik dua (:) dan dibaca "adalah untuk." Jadi, untuk sembarang bilangan real x dan sembarang bilangan real tak nol y , persamaan ini berlaku:

x y = x : y

Dengan kata lain:

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

Saya tahu itu akan membutuhkan sedikit tweaker parser untuk menggunakan titik dua dalam matematika, tetapi tampaknya _is_ secara matematis. Saya tidak bisa memikirkan simbol lain yang bisa menjadi pengganti yang lebih baik. Mungkin | sebagai pilihan kedua? Itu akan lebih sewenang-wenang sekalipun.

Pikiran?

_Atau_, kami masih dapat mendukung simbol pembagian dalam tanda kurung dan/atau kurung, seperti pada:

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

Yap, itu sebabnya awalnya saya mulai dengan ./ (terinspirasi oleh operator div vektor Matlab, ini adalah dua simbol tetapi secara visual mungkin yang paling ringan karena titik yang ringan, meskipun dalam konteks Kurang merusak titik tidak ide yang brilian).
: - Ini akan mendorong bunga aster sekali lagi, simbol ini digunakan dalam terlalu banyak konteks CSS. Sebenarnya sudah ada sintaks yang saling bertentangan:

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

@seven-phases-max Ah, ya, sial. JIKA KEYBOARD LEBIH BESAR. Ya, urutan 2 karakter untuk pembagian tampaknya tak terelakkan. Sudah lama sejak saya membaca seluruh utas, jadi saya lupa tentang itu. ./ Benar-benar tidak buruk. Jika Anda dan @lukeapage bergabung, itu bukan kompromi yang buruk. Mungkin kita pindahkan ke tahap proposal, dan lihat apakah ada keberatan?

Membaca kembali, ke titik ini:

tidak menghitung itu juga membutuhkan spasi putih sebelum . , misalnya 16 ./17 dan bukan 16./17

Tidak yakin saya setuju. Ya, 16. adalah angka yang valid, secara teknis, tetapi akan aneh bagi seseorang untuk menulisnya seperti itu. Saya pikir tidak peduli bagaimana Anda akan menulisnya, spasi atau tidak, itu harus membagi 16 dengan 17.

Tidak akan ada pilihan yang sempurna, tapi saya pikir itu lebih baik daripada a) Menggunakan / untuk pembagian secara default, b) selalu membutuhkan tanda kurung. (Meskipun posisi saya di masa lalu, saya juga datang sekitar ya, itu agak menjengkelkan, terutama dalam tanda kurung lainnya. Dan terutama karena itu hanya diperlukan karena pembagian, untuk pengetahuan saya. Ya?)

Saya pikir tidak peduli bagaimana Anda akan menulisnya, spasi atau tidak, itu harus membagi 16 dengan 17.

Ya memang.
Meskipun memikirkannya lebih, saya berharap ./ untuk menempatkan beberapa tipuan tambahan ke parser (penguraian angka akan membutuhkan pandangan ekstra ke depan untuk berhenti sebelum ./ sementara saat ini selalu memakan akhir . ).

Dan terutama karena itu hanya diperlukan karena pembagian, sepengetahuan saya. Ya?)

Iya benar sekali. Tidak termasuk kode di dalam calc - tetapi untuk yang ini saya kira solusi yang disarankan oleh @lukepage harus berhasil.

(Secara teknis, di masa depan mungkin ada beberapa ambiguitas tambahan untuk +, -, * jika mereka tetap menggunakan sintaks fungsi manipulasi warna CSS - tetapi ini tidak boleh terlalu dramatis karena nilai di sana memiliki bentuk * 20% (dengan demikian mereka jelas dapat dideteksi sebagai beberapa expr yang tidak dievaluasi kurang) Setelah semua kesenangan itu akan memerlukan beberapa perubahan penguraian karena saat ini nilai seperti (* 20%) menyebabkan kesalahan penguraian).

Mungkin... kita selama ini salah. (Pasti termasuk saya di dalamnya, karena saya adalah pendukung awal fitur "matematika ketat".)

Kami mencoba membuat matematika bekerja secara universal, tapi.... sebenarnya tidak perlu. Artinya, kami mencoba melakukan matematika dalam kasus di mana seharusnya jelas bahwa tidak ada matematika yang harus dilakukan.

Contoh calc(100% - 10px) adalah yang paling jelas. Tidak ada perhitungan Less yang dapat/harus dilakukan kecuali kita menggunakan unit, yang saya setuju Less harus berhenti dilakukan, secara default. ¹

Mari kita lihat properti font shorthand yang digunakan sebagai contoh.

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

Solusi saat ini untuk ini adalah mengubah strict-math: on untuk properti font. Tapi... mengapa Less harus melakukan perhitungan sejak awal? Tentu, 13px/150% adalah pernyataan yang valid dalam matematika, tetapi apakah masuk akal untuk memperlakukannya sebagai valid dalam Kurang? 12px/30px Anda _bisa_ memperlakukannya sebagai pernyataan matematika yang valid, tetapi haruskah Anda? ²

Yaitu: di Kurang, operasi matematika pada unit harus dilakukan oleh _integers_ dan _floats_, bukan unit. Kami memperlakukan ini sebagai pernyataan matematika yang valid, seolah-olah orang benar-benar menulis matematika mereka dengan cara ini. Tapi saya tidak melihat bagaimana itu mungkin benar.

Artinya, masuk akal untuk meminta seseorang menulis 13px/150% sebagai 13px/1.5 . Dan bahkan mengabaikan fakta bahwa 12px/30px tidak masuk akal sebagai operasi matematika, kita tidak perlu tahu bahwa itu tidak masuk akal, dan kita tidak perlu memasukkan font ke daftar putih . Jika penulis Less melakukan operasi matematika, mereka akan menulisnya 12px/30 . Tidak hanya itu masuk akal, kemungkinan besar itulah _bagaimana mereka menulisnya sejak awal_.

Sudah biasa bagi saya untuk menulis mixin atau bahkan menggunakan sesuatu seperti ini dalam satu blok:

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

Mengapa saya menulisnya seperti ini? Apakah _anyone_ menulisnya seperti ini?

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

Operasi _sort of_ masuk akal jika @size adalah unit px , tetapi, terlepas dari itu, kurang masuk akal dalam bidang KURANG/CSS untuk mencoba melakukan matematika dalam kasus terakhir ketika pembagi adalah nilai dengan satuan. Yang kedua tidak terlihat seperti matematika. Sepertinya nilai CSS.

Jika kita berhenti melakukan operasi matematika untuk perkalian atau pembagian (hanya pembagian diperlukan untuk ambiguitas, tetapi perkalian juga untuk konsistensi logis) ketika pengali atau pembagi adalah nilai dengan unit, saya pikir masalah ini sebagian besar akan hilang. Sebaliknya, unit _are_ logis untuk penambahan dan pengurangan, tetapi mungkin tidak perlu diperlukan (begitulah sekarang).

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

Tetapi ketika menambah/mengurangi satu nilai dengan satuan lain dengan satuan yang berbeda, Less sebaiknya dibiarkan saja.

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

Membutuhkan unit yang cocok untuk penambahan / pengurangan (atau integer / float), dan membutuhkan bilangan bulat / float dalam operasi matematika terhadap unit (tidak ada unit dikalikan / dibagi dengan unit) akan memecahkan 99% ambiguitas, dan masih memungkinkan operasi matematika yang valid tanpa simbol baru .

Misalnya, berdasarkan aturan tersebut, singkatan latar belakang akan baik-baik saja:

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

% adalah unit CSS. px adalah unit CSS yang berbeda. Oleh karena itu, tidak ada matematika. Pengecualian khusus akan menjadi nol.

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

Jika seseorang tampaknya membagi nol dengan angka lain, atau membagi angka dengan nol, saya pikir kita dapat dengan aman mengeluarkan apa adanya.

Batas-radius, hal yang sama:

border-radius: 30% / 20%;

Kurang akan memberikannya izin. Jika seseorang berniat untuk mengerjakan matematika, cara yang tepat untuk menulisnya adalah:

border-radius: 30% / 0.2;

Hal yang menyenangkan adalah, dengan membuat perbedaan ini, akan terlihat jelas bahwa operasi matematika _tidak bisa_ menjadi nilai CSS, karena, seperti contoh border-radius , nilai CSS yang valid akan memerlukan unit di kedua sisi. Tidak akan ada tumpang tindih/ambiguitas.

Kecuali satu kasus yang dapat saya pikirkan, dan mungkin ada yang lain:

font: 10px/1.5;

Anda dapat (dan biasanya harus) mewakili tinggi garis hanya sebagai angka. (Tetapi juga mungkin tidak boleh menggunakan singkatan font.) Tetapi jika kita telah menguranginya menjadi satu kasus, itu cukup bagus. Mengaktifkan matematika ketat untuk font (kecuali untuk fungsi di dalam dalam nilai font) adalah solusi yang baik. (Saya tidak yakin tidak ada yang lebih baik, tetapi itu berhasil.) Dan masih merupakan solusi dengan kerusakan paling rendah, karena nilai singkatan font tersebut biasanya muncul di pustaka gaya UI yang diimpor, penyetelan ulang CSS, atau lembar gaya font khusus.

Jadi, masih ada gunanya matematika ketat, tapi saya pikir dengan perubahan ini, kurang begitu, dan mungkin tidak diperlukan sebagai pilihan di masa depan.

Saya menyambut tanggapan / komentar dari galeri.

¹ _Saya menyadari bahwa saya harus menjelaskan bahwa komentar @lukeapage , dan tautan @seven-phases-max ke
² _Seperti yang saya ketahui saat melihat contoh, mengaktifkan matematika yang ketat untuk font mungkin merupakan solusi yang tidak dapat dihindari, tetapi saya pikir logika lainnya berlaku._

Hanya untuk beberapa konteks historis, penting untuk dicatat bahwa casting unit ketika Less.js pertama kali dirilis tidak terlalu menjadi masalah. calc() tidak diterapkan, dan background dan border-radius tidak memiliki garis miring sebagai nilai yang valid. Saya pikir font adalah satu-satunya tempat yang membuat segalanya tersandung (yang, ironisnya, mungkin masih terjadi).

Satu-satunya kekhawatiran saya adalah sisi implementasi, misalnya: untuk calc(4px + 2rem + 20%) (unit sebenarnya tidak masalah), penambahan pertama menghasilkan hasil yang tidak lagi numerik, sehingga penangan tambahan kedua tidak dapat membedakan inputnya dari pernyataan not-a-number + 20% apa pun yang seharusnya menimbulkan kesalahan. Bukan masalah besar mungkin (dapat dipecahkan dengan meletakkan tipe/tipe-flag tambahan), tetapi masih perlu diselidiki.

Dan kekhawatiran lainnya adalah ehm, tidak yakin, "redabilty"? Yaitu sementara untuk angka eksplisit hasilnya terlihat sangat jelas, untuk variabel mulai terlihat cukup ambigu, misalnya: border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - Anda tidak pernah tahu apa artinya ini sampai Anda melihat @a dan @b definisi.

Dan ya, font masih tetap menjadi masalah (kemungkinan properti singkatan lain tampaknya menggunakan unit di kedua sisi tetapi sekali lagi kita tidak pernah tahu apa yang mereka hasilkan selanjutnya (juga menghitung hal-hal seperti #2769... A beberapa barang lagi seperti font dan itu akan mulai terlihat rusak lagi).

PS Satu masalah lagi (mungkin regresi kecil). Ada nilai-nilai seperti:

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

Yaitu agar semuanya berfungsi, kita harus menonaktifkan semua kesalahan incompatible-div-operand saat ini sehingga foo/bar , 1x/bar dan foo/1x dapat lulus w/oa kesalahan.

Satu-satunya kekhawatiran saya adalah sisi implementasi, misalnya: untuk calc(4px + 2rem + 20%) (unit aktual tidak masalah)

Inilah yang saya katakan. Unit sebenarnya harus penting. Kurang harus meninggalkan itu sendirian, terlepas dari itu. 4px + 2rem memiliki arti di browser, tetapi tidak berarti di Less. Tidak ada alasan untuk mencoba menambahkannya saat tidak masuk akal, dan menyebabkan masalah pengaya ini.

misalnya: border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - Anda tidak akan pernah tahu apa artinya ini sampai Anda melihat definisi @a dan @b .

Ini adalah kasus di mana kita tidak dapat menyelamatkan penulis gaya dari diri mereka sendiri (sama dengan contoh pertama, jika seseorang benar-benar mencoba menambahkan rem ke piksel karena suatu alasan). Saya yakin ada berbagai macam contoh yang ada di mana seseorang dapat menulis kode KURANG mereka sehingga membingungkan untuk diikuti. Itu ada di mana saja.

Dengan aturan matematika yang saya usulkan, pertimbangkan:
calc(4px + 2rem - 2px)

Kurang yang bisa/akan menghitungnya sebagai calc(2px + 2rem) , yang sebenarnya baik-baik saja, dan sebenarnya merupakan output nilai yang benar. Saat ini, Less menghitungnya sebagai calc(4px) , yang bukan merupakan jawaban yang benar atau berguna. (Ya, saat ini benar jika kita menjatuhkan unit, tetapi unit tidak berarti, dan kecuali untuk beberapa kasus, tidak dapat dioperasikan.) Less menghitung 2px + 100% sebagai 102px , seolah-olah ada beberapa nilai dalam hasil itu, ketika tidak ada yang mungkin menginginkan itu sebagai hasilnya.

agar semuanya berfungsi, kita harus menonaktifkan kesalahan-div-operan yang tidak kompatibel saat ini sehingga setiap foo/bar, 1x/bar, dan foo/1x dapat melewati kesalahan w/oa.

Saya pikir itu sebenarnya cara paling waras untuk mengobatinya. Seperti fungsi, jika tidak ada hasil Kurang, maka itu harus melewati. Karena / adalah pemisah yang valid untuk lebih dari satu nilai properti, Less tidak dapat mengetahui bahwa itu _tidak_ valid, kecuali jika kita menambahkan nilai yang masuk daftar putih untuk properti tertentu. (Tidak.) Pada titik itu, hasilnya tidak tragis. Jika nilai pass-through tidak valid di browser, itu terlihat secara visual. Tampaknya lebih baik untuk mencoba meneruskan nilai ke browser jika itu valid, daripada membuat kesalahan karena Less tidak yakin.

Kurang bisa/akan menghitungnya sebagai calc(2px + 2rem)

Saya khawatir itu tidak akan pernah terjadi karena ini akan membutuhkan penangan ekspresi pengoptimalan baru yang akan berlebihan (pada dasarnya 4px + 2rem - 2px disimpan di pohon sebagai (4px + 2rem) - 2px jadi untuk mendapatkan 2px + 2rem itu harus menjadi mesin pemesanan ulang untuk mencoba semua pengacakan yang valid (sepele dalam kasus khusus ini tetapi menjadi cukup rumit untuk lebih banyak operan/operator). Tapi tidak apa-apa, membiarkan 4px + 2rem - 2px apa adanya tidak masalah (setelah semua jika Anda melakukan 4px - 2px + 2rem itu dioptimalkan).

Tapi apa yang sebenarnya saya maksud dengan komentar itu adalah hal yang mirip dengan:

sehingga setiap foo/bar, 1x/bar dan foo/1x dapat melewati kesalahan w/oa.

Yaitu (4px + 2rem) - 2px untuk expr.evaluator akan mirip dengan foo + 2px , sehingga untuk berfungsi seharusnya tidak menghasilkan kesalahan untuk hal-hal semacam itu juga.
Sebenarnya, saya menguji foo/bar, 1x/bar, foo/1x dan mereka sudah lulus tanpa kesalahan (aneh saya pikir mereka melempar), tetapi operator lain menghasilkan segala macam hal aneh (tidak ada yang benar-benar kritis, hanya masalah memperbaiki setiap kasus satu per satu).

Saya khawatir itu tidak akan pernah terjadi karena ini akan membutuhkan pengendali ekspresi pengoptimalan baru yang akan berlebihan (pada dasarnya 4px + 2rem - 2px disimpan di pohon sebagai (4px + 2rem) - 2px jadi untuk mendapatkan 2px + 2rem sudah menjadi mesin pemesanan ulang untuk mencoba semua pengocokan yang valid (sepele dalam kasus khusus ini tetapi menjadi cukup rumit untuk lebih banyak operan/operator).

Mengapa mengocok? Anda meratakan operator pada tingkat prioritas yang sama (jadi pohonnya adalah Sum(4px, 2rem, -2px) ), mengumpulkan suku-suku dengan unit yang kompatibel (mungkin dengan menormalkan unit sebelumnya), dan menyederhanakan setiap bagian. Ini aljabar simbolis, di mana unit diperlakukan sebagai variabel independen.

Saya ingin menulisnya sendiri, tetapi ada banyak perpustakaan di luar sana yang mungkin lebih teruji dan lebih mungkin lengkap. Saya berani bertaruh beberapa kompiler pengoptimalan sumber terbuka yang ditulis dalam Javascript memiliki subsistem penyederhanaan seperti itu.

Intinya adalah, meskipun ini bukan masalah yang mudah untuk dipecahkan, masalah yang lebih umum sudah diselesaikan dengan cukup baik, dan subsistem semacam itu dapat berguna untuk Less.js dengan cara lain.

Anda meratakan operator pada tingkat prioritas yang sama (jadi pohonnya adalah Sum(4px, 2rem, -2px)),

Dan apa sebenarnya yang membuat kode untuk berpikir beberapa pohon ekspresi sebenarnya bisa diratakan sama sekali? (Jadi "suffling" saya bukan tentang beberapa algoritma deduksi tertentu, tetapi jalan pintas untuk "coba semuanya" termasuk "flatten" Anda.

tetapi ada banyak perpustakaan di luar sana yang mungkin lebih teruji dan lebih mungkin lengkap.

Saya tidak yakin apakah Anda serius. Jadi menurut Anda semua kode untuk mengonversi Less tree ke pohon lib eksternal dan kembali (tidak termasuk tidak ada lib JS yang dapat menangani unit CSS) sebenarnya bernilai 4px + 2rem - 2p case khusus untuk dioptimalkan? Hmm...

Jadi, tidak ada masalah sama sekali (saya tidak mengatakan itu tidak mungkin hanya bahwa itu tidak akan pernah sia-sia) - coba dan PR diterima.
(Juga untuk berjaga-jaga mungkin penting untuk dicatat bahwa hal pengoptimalan subekspresi bahkan bukan tujuan tiket ini, bahkan di tiga teratas).

Dan apa sebenarnya yang membuat kode untuk berpikir beberapa pohon ekspresi sebenarnya bisa diratakan sama sekali? (Jadi "suffling" saya bukan tentang beberapa algoritma deduksi tertentu, tetapi jalan pintas untuk "coba semuanya" termasuk "flatten" Anda.

Pengurai menentukan apakah konteksnya misalnya "panjang", dan apakah subpohon dapat ditafsirkan sebagai "panjang".

Saya tidak yakin apakah Anda serius. Jadi Anda berpikir bahwa semua kode itu untuk mengonversi Lebih sedikit pohon ke pohon lib eksternal dan kembali

Itu perlu diuraikan menjadi pohon sintaksis. Dari sana, akan relatif mudah untuk mengeluarkan string yang mewakili ekspresi aljabar. Kembali mungkin lebih sulit: mungkin perlu diuraikan lagi dari string, atau ya, mungkin perlu mengambil pohon lib eksternal. Kesulitannya tergantung pada perpustakaan mana yang dipilih.

(tidak termasuk lib JS yang dapat menangani unit CSS)

Anda baru saja mengonversi unit ke variabel aljabar. Substitusi (misalnya mm -> px ) bahkan dapat dilakukan saat ekspresi dalam bentuk simbolis.

apakah benar-benar layak untuk kasus 4px + 2rem - 2p tertentu untuk dioptimalkan?

Saya membuat saran alternatif untuk pengoptimalan ekspresi yang tidak terlalu sulit (sebagai masalah algoritme yang harus diselesaikan oleh kode Less sendiri) dan lebih berguna secara umum daripada yang Anda katakan perlu.

Penyederhanaan aljabar dapat menyelesaikan masalah dengan subekspresi yang diberi tanda kurung, dan memungkinkan Less untuk menambahkan lebih banyak fitur matematika.

mencoba dan PR dipersilahkan.

Saya akan mencoba. Saya baru mulai melihat Less hari ini, dan saya memiliki masalah dalam menyelesaikan proyek, jadi saya akui bahwa saya mungkin tidak akan mendapatkan PR.

Juga untuk berjaga-jaga mungkin penting untuk dicatat bahwa hal pengoptimalan subekspresi bahkan bukan tujuan tiket ini, bahkan di tiga besar

Aku tahu. Saya di sini untuk salah satu alasan. Mengapa gigitan seperti itu?

Mengapa gigitan seperti itu?

Yah, mungkin... Jika demikian - saya minta maaf (Sepertinya saya terlalu terkejut dengan upaya dan waktu seseorang siap untuk mendedikasikan untuk memecahkan hampir tidak ada masalah calc(4px + 2rem - 2px) . Mungkin kita hanya memiliki gagasan yang sangat berbeda ringan).

dan izinkan Less untuk menambahkan lebih banyak fitur matematika.

Bisakah Anda menyebutkan beberapa?

untuk memecahkan hampir tidak ada masalah calc(4px + 2rem - 2px)

Hah? Less tidak bisa menangani itu sama sekali. [sisanya dihapus karena saya salah memahami apa yang sedang dibahas]

Untuk menyederhanakan / menyatakan kembali proposal - Perubahan matematika akan menjadi sebagai berikut

1. Penambahan dan pengurangan hanya akan dihitung pada unit yang sama. misalnya 1px + 2px = 3px , 1px + 1vh = 1px + 1vh
2. Pembagian dan perkalian hanya akan dihitung dengan pembagi/pengganda tanpa unit. misalnya 10px/2 = 5px , 10px/5px = 10px/5px
3. Rasio nilai tanpa unit akan diperlakukan sama dengan # 2. misalnya 1/3 = 1/3
4. Untuk penyederhanaan, ekspresi dengan sub-ekspresi yang tidak valid sebagian dapat diperlakukan sebagai ekspresi matematika yang tidak valid dan output apa adanya. misalnya 1px + 2vh / 2 = 1px + 2vh / 2

Proposal ini menyelesaikan yang berikut (dari utas ini):

• font: 10px/5px dan sintaks (rasio) serupa (tanpa perhitungan)
• calc(100vh - 30px) (tanpa perhitungan)
• lost-column: 1/3 dan sintaks rasio khusus yang serupa (tanpa perhitungan)

Pada saat yang sama, perubahan ini akan mempertahankan 99% dari penggunaan matematika Less pada umumnya. Selain itu, fungsi unit() dan convert() memungkinkan pengguna untuk memasukkan nilai ke dalam unit yang kompatibel untuk matematika.

Less tidak bisa menangani itu sama sekali.

Anda hanya tidak membaca apa yang saya dan @leewz bicarakan di atas. Itu tidak ada hubungannya dengan calc(100vh - 30px) . Dan "untuk memecahkan hampir semua masalah yang tidak ada" saya hanya "mengoptimalkan ekspresi aritmatika dalam calc ".

@seven-phases-max Ohhh benar itu. Maaf. Tidak, kita tidak perlu mengoptimalkan. Cari tahu kapan harus matematika.

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.

Menghapus label slate karena masalahnya masih penting dan semakin buruk seiring berkembangnya CSS.

@matthew-dean
Akan bermain advokat iblis sejenak di sini ...

12px/30px Anda _bisa_ memperlakukannya sebagai pernyataan matematika yang valid, tetapi haruskah Anda melakukannya?

Ya; Anda harus. Ini menghitung nilai skalar yang mewakili rasio antara kedua ukuran dan itu bisa sangat berguna saat mengonversi ke satuan em.

Katakanlah saya memiliki ukuran font dasar yang diketahui 16px dan ukuran heading yang diketahui 24px, keduanya tersimpan dalam variabel, dan kemudian saya ingin menetapkan cita rasa tertentu dari heading dengan ukuran font yang benar, tetapi dalam unit 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;
}

Dan jika Anda perlu mendukung pembagian unit yang kompatibel sebagai ekspresi matematika, maka Anda akan terus perlu mendukung cara untuk membedakan CSS literal dari ekspresi matematika Kurang untuk mencakup setiap setengah kasus.

Sekarang diberikan, itu bisa melibatkan penggunaan parens untuk memaksa ekspresi matematika dan mengambil literal CSS secara default. Tapi itu tampaknya salah dan rawan kesalahan. Ini membutuhkan banyak kasus khusus yang sudah dimasak sebelumnya seperti di border-radius dan font steno, dan mengharuskan Less untuk terus memperbaruinya. (Seperti yang telah diilustrasikan oleh beberapa properti grid baru yang mengembangkan masalah yang sama dengan tanda pembagian.)

Jadi...

Mengapa tidak membalik alasan Anda? Jika sesuatu terlihat seperti ekspresi matematika dan memiliki unit yang kompatibel maka itu akan diperlakukan sebagai ekspresi matematika secara default. Dan jika Anda tidak ingin itu terjadi ... yah; kemudian gunakan pintu keluar ~"..." . Ini persis untuk apa itu ada, setelah semua ...

Visi saya saat ini tentang proposal:

• Berhentilah memperlakukan / sebagai pembagian di mana saja terlepas dari untis apa pun dan terlepas dari opsi apa pun (kecuali - secara opsional - itu diapit oleh paren yang berlebihan seperti dengan -sm=on)
  Jadi hanya 1anything./3whatever dan (opsional) (1anything/3whatever) yang dievaluasi oleh Less.
• + , - dan * tetap tidak berubah
• Submasalah calc diselesaikan dengan tidak mengevaluasi aritma apa pun . ekspresi di dalam calc(...) (meskipun, sekali lagi, parens yang berlebihan mungkin juga memiliki efeknya).

@seven-fase-max

Masalah dengan itu adalah / sangat mendarah daging sebagai operator divisi. Menggunakan simbol lain untuk itu akan menjadi penjualan yang sulit bagi pengguna. Anda mengambil kasus penggunaan umum dan membuangnya untuk kasus penggunaan luar biasa ( / dalam singkatan CSS) yang hampir tidak pernah digunakan siapa pun.

@rjgotten

Masalahnya adalah / sangat mendarah daging sebagai operator divisi.

Tidak di CSS.

untuk kasus penggunaan luar biasa (/ dalam singkatan CSS) yang hampir tidak pernah digunakan siapa pun.

Sekarang / sudah banyak digunakan , dan sebagai perbandingannya, Less div op benar-benar jauh lebih luar biasa daripada CSS / akhir-akhir ini (tidak seperti beberapa tahun yang lalu di mana CSS / sebagian besar dapat ditemukan dalam font saja).

@seven-phases-max Terima kasih telah terus memantaunya. Saya menambahkan bot Stale untuk membantu kami mengelola masalah dan memberikan cukup banyak waktu untuk menandai basi. Saya juga mengecualikan dua label, "bug" dan "up-for-grabs". Setiap saran tentang itu dipersilakan, seperti label lain ke daftar putih. File ada di sini: https://github.com/less/less.js/blob/3.x/.github/stale.yml

Kembali ke topik masalah...

@rjgotten
Kasus penggunaan Anda menciptakan masalah sewenang-wenang. Argumennya adalah bahwa itu berguna. Tetapi menyusun vars Anda seperti itu menciptakan masalah yang dapat dihindari dengan sintaks yaitu, seperti yang ditunjukkan @seven-phases-max, ambigu.

Bahkan jika dilihat dari nilai nominalnya, dengan CSS sebagai panduan untuk prinsip-prinsip Kurang, Anda tidak dapat, dalam perhitungan, membagi 12px dengan 30px. Melakukannya di Less tidak hanya menciptakan masalah ambiguitas, tetapi juga memecahkan model tanpa alasan yang baik (selain historis). Mungkin salah satu hal yang hilang dari Less hanyalah cara untuk mengekstrak nilai numerik dari nilai satuan sehingga Less tidak perlu melakukan keajaiban matematika ini untuk pembagian.

Jadi, jawaban sederhananya adalah contoh Anda akan terlihat seperti:

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

Tapi saya setuju dengan proposal @seven-phases-max juga. Kami masih dapat mengevaluasi _vars_ dalam calc() , tetapi bukan matematika. Dan tidak mengevaluasi pembagian di luar parens. Saya pikir itu kompromi yang bagus. Dan, mungkin, jika Anda ingin mempertahankan matematika pembagian ajaib dengan membagi unit dengan unit tetapi mempertahankan unit (yang masih aneh, tapi tidak apa-apa), itu bisa terjadi di dalam parens.

Saya tahu ada beberapa preferensi yang berbeda pada subjek matematika di Less, tapi saya pikir akan sangat bagus jika kita dapat mencapai konsensus tentang sesuatu yang menyebabkan efek samping paling sedikit dan paling mudah untuk dipikirkan tanpa menyebabkan pemeliharaan yang besar. atau beban pembangunan.

Saya pikir kita semua berada di halaman yang sama bahwa pendekatan (default) saat ini untuk matematika di Less rusak. Dan kami menerima umpan balik bahwa meng-parens-semuanya sebagai default lebih mudah untuk dipikirkan, tetapi memberatkan. Jadi saya berharap ada jalan tengah yang bagus yang bisa segera kita masukkan sebagai default (mungkin di 4.0?)

Mungkin salah satu hal yang hilang dari Less hanyalah cara untuk mengekstrak nilai numerik dari nilai satuan

Fungsi unit benar-benar melakukannya jika Anda tidak menentukan parameter kedua. Tapi itu lebih merupakan efek samping dari fakta bahwa skalar saat ini diimplementasikan dengan tipe simpul Dimension yang tidak memiliki unit yang ditentukan.

Diberikan; itu berjalan jauh, tetapi jika Anda _benar-benar_ ingin menghindari pembagian dimensi yang memiliki unit yang kompatibel, maka merobek unit akan berhasil.

Saya juga menambahkan bahwa saya sangat menentang dugaan "unit yang kompatibel" (seperti biarkan a/b tetap menjadi divisi dan b/c tidak) dalam konteks khusus ini.
Hanya karena:

• penanganan yang luar biasa adalah akar dari semua kejahatan (misalnya #3047 - lihat di bawah, http://stackoverflow.com/questions/19705791- Saya ingat saya tidak dapat menemukan alasan untuk masalah SO sampai saya benar-benar melangkah melalui setiap miliaran baris dari kode Lebih sedikit yang terlibat dalam debugger).
• dan yang paling penting, itu tidak tahan masa depan, yaitu jika perubahan besar tidak dapat dihindari, sebaiknya kita memastikan untuk membuatnya sekali (dan idealnya selamanya)... dan tidak seperti mereka menambahkan beberapa fitur CSS baru yang melibatkan a/b dan itu rusak lagi.

Jadi bagi saya hal-hal "Unit yang Kompatibel" lebih seperti hal yang sama sekali tidak terkait dan ortogonal (mungkin ada beberapa diskusi tentang unit yang dihasilkan dengan atau tanpa -su , tapi itu cerita lain).

(keluar topik:)
Dan btw., berbicara tentang contoh di atas:
@rjgotten jika Anda memiliki:

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

di suatu tempat dalam kode Anda dan salah satu dari dua variabel adalah px Anda benar-benar menggunakan bug :)
Kode yang tepat adalah:

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

Ini selalu menghasilkan unit yang terdefinisi dengan baik per http://lesscss.org/features/#features -overview-feature-operations (menghitung #3047 untuk diperbaiki, bug lagi-lagi merupakan contoh bug yang dihasilkan terlalu banyak kode tebakan di sekitar "unit yang kompatibel" di basis kode). Tidak perlu --su , number , unit bla-bla... Perilaku -su seperti "lemparkan saja kesalahan jika Anda melihat unit yang tidak kompatibel" , yaitu validasi sederhana, lebih dari cukup (bagi saya). Saya tidak melihat perlunya 1px/2px->.5 dan 1px*2px->2px^2 mambo-jambo overengineering. Tapi sekali lagi ini adalah cerita lain yang tidak berhubungan).

@seven-fase-max

sebenarnya menggunakan bug

Hmm.. ya; Anda benar, tentu saja. Untungnya saya tidak benar-benar memiliki kode itu dalam produksi di mana pun. Itu hanya contoh cepat yang digabungkan untuk mengilustrasikan intinya.

Saya juga menambahkan bahwa saya sangat menentang dugaan "unit yang kompatibel" (seperti biarkan a/b tetap menjadi divisi dan b/c tidak) dalam konteks khusus ini.

Saya pikir saya setuju dengan itu lebih sebagai cabang zaitun bagi mereka yang menginginkan pembagi telanjang. Tapi saya pikir komentar Anda [ di sini ] adalah proposal yang paling bisa diterapkan. Itu adalah niat asli dari "matematika ketat", untuk menghilangkan ambiguitas. Saya pikir kekhawatiran menjadi operasi dalam mixin dan panggilan fungsi yang mengarah ke semua jenis parens di dalam parens. Tapi, secara umum, saya setuju dengan Anda bahwa upaya untuk membuat matematika menjadi mudah di Less juga, ironisnya, membuatnya sangat sulit, karena meningkatnya ambiguitas.

Juga, saya kemudian menyadari bahwa font: 10px/3 adalah singkatan yang valid. Jadi sebenarnya tidak ada solusi algoritmik yang dapat membantu di sana.

Untuk kembali ke pertanyaan Anda, @rjgotten...

Mengapa tidak membalik alasan Anda? Jika sesuatu terlihat seperti ekspresi matematika dan memiliki unit yang kompatibel maka itu akan diperlakukan sebagai ekspresi matematika secara default. Dan jika Anda tidak ingin itu terjadi ... yah; kemudian gunakan ~"..." escape hatch. Ini persis untuk apa itu ada, setelah semua ...

Ide/hubungan Less dengan CSS mirip dengan TypeScript dengan JavaScript. Yaitu, ganti nama .css valid Anda menjadi .less dan Anda dapat mulai menambahkan Lebih sedikit fitur. Mirip dengan bagaimana Anda dapat mengganti nama .js menjadi .ts dan mulai menambahkan fitur TypeScript. Jika Anda tidak menambahkan apa pun, Anda akan mendapatkan output Less/JavaScript yang sama validnya, karena bahasanya adalah superset dari bahasa dasar.

Namun, dalam kasus rasio ini atau pembagi / di CSS, Less sudah langsung gagal, secara default. CSS reguler Anda secara sewenang-wenang menjadi ekspresi Less math dengan hasil yang berbeda, meskipun Anda tidak mengubah apa pun. Itu melanggar kontrak bahasa. Mampu mengubah .less menjadi ekspresi Less yang sama sekali berbeda untuk mendapatkan kembali CSS asli yang Anda mulai tidak tepat. Pekerjaan itu seharusnya tidak pernah diperlukan. Less seharusnya tidak mengharuskan Anda untuk mengubah CSS yang valid menjadi ekspresi Less yang kompatibel untuk mendapatkan kembali CSS valid yang Anda miliki di tempat pertama. Itu hanya model yang rusak.

Alasan yang sama berlaku untuk calc() . Ya, Anda dapat melakukan string-escape dari ekspresi Anda, tetapi Anda tidak harus melakukannya. .css diganti namanya menjadi .less akan menghasilkan CSS efektif yang sama. Ini harus menjadi tujuan dasar proyek, untuk tidak mengganggu / menimpa / menginterpretasikan stylesheet asli secara berlebihan. Ada lagi yang mencoba mendorong masalah ke pengembang tanpa dosa selain menggunakan parser/bahasa di tempat pertama.

Ya, Anda dapat melakukan string-escape dari ekspresi Anda, tetapi Anda tidak harus melakukannya. .css berganti nama menjadi .less akan menghasilkan CSS efektif yang sama. Ini harus menjadi tujuan dasar proyek, untuk tidak mengganggu / menimpa / menginterpretasikan stylesheet asli secara berlebihan. Ada lagi yang mencoba mendorong masalah ke pengembang tanpa dosa selain menggunakan parser/bahasa di tempat pertama.

Itu.

KURANG tahu di mana / diperbolehkan dan tidak di css. Di mana tidak tetapi tetap muncul, itu harus menganggap matematika harus dilakukan. Juga di mana matematika dikelilingi oleh tanda kurung bulat di mana tanda kurung bulat tidak diperbolehkan di css harus ditafsirkan oleh KURANG.

Dengan kata lain, KURANG harus mencoba menafsirkan matematika sesedikit mungkin untuk mendapatkan css yang valid. Segera setelah output valid, berhenti mengeksekusi matematika lagi.

@thany

Terlalu banyak asumsi tentang apa yang diketahui kompiler (dan beberapa di antaranya salah).
Either way mode "kurung bulat" hampir seperti yang dilakukan --sm=on , jadi gunakan itu dan lupakan utas ini (kemungkinan besar Anda tidak menggunakan matematika apa pun dalam proyek Anda selain calc (memperkenalkan beberapa tahun setelah Less dirancang) sehingga Anda tidak dapat melihat bagaimana parens tambahan mengganggu. Tetapi yang lain melakukannya.)

Selebihnya lihat https://github.com/less/less.js/issues/1880#issuecomment -345194431.

@seven-phases-max Jangan lupa bahwa / juga memiliki arti dalam background dan border-radius steno, dan mungkin yang lain yang tidak saya pikirkan sekarang. KURANG akan dengan senang hati memperlakukannya sebagai sebuah divisi. Dengan atau tanpa mode matematika yang ketat, KURANG harus "tahu kapan harus berhenti" melakukan matematika kecilnya sendiri.

@thany
KURANG harus "tahu kapan harus berhenti" melakukan matematika kecilnya sendiri.

Tidak, seharusnya tidak. Tidak ada cara untuk mengetahui di mana steno CSS masa depan dengan garis miring akan muncul. Memiliki kompiler yang Kurang 'tahu' tentang itu adalah pendekatan yang pada dasarnya cacat dan hal yang sedang dicoba untuk dicari solusinya oleh diskusi ini.

Sejauh ini ada dua pilihan, waras dan dapat diprediksi untuk / sebagai operator divisi:

• Selalu perlakukan seperti itu dan memerlukan pelarian eksplisit untuk penggunaan lain.
  Ini akan mematahkan perilaku di mana sintaks Less adalah superset ketat dari sintaks CSS.
• Jangan pernah memperlakukannya sebagai operator pembagian, __kecuali__ itu berada dalam konteks matematika yang diketahui.
  Di mana konteks matematika yang diketahui dapat/akan diputuskan seperti pada perilaku --strict-math=on .

_{(Juga; harap perhatikan bahwa nama Lebih Sedikit tidak lagi dieja dengan huruf besar semua.)}

Jangan lupa bahwa / juga memiliki arti di latar belakang dan singkatan radius batas,

Ini pada dasarnya adalah apa yang dimulai dengan utas ini.
Dan lihat ringkasan perubahan yang diusulkan di https://github.com/less/less.js/issues/1880#issuecomment -345194431 (tanpa asumsi tentang apa yang harus atau tidak boleh diketahui oleh kompiler).

Tidak, seharusnya tidak. Tidak ada cara untuk mengetahui di mana steno CSS masa depan dengan garis miring akan muncul. Memiliki kompiler yang Kurang 'tahu' tentang itu adalah pendekatan yang pada dasarnya cacat dan hal yang sedang dicoba untuk dicari solusinya oleh diskusi ini.

Saya setuju dengan ini sepenuhnya. @thany Sementara Anda setuju dengan saya dalam apa yang Anda kutip dari apa yang saya tulis, Anda sampai pada kesimpulan yang berbeda dari yang saya buat. Less tidak boleh dan tidak tahu kapan harus "berhenti mengerjakan matematika". Apa yang akan saya katakan adalah bahwa perubahan yang paling penting adalah bahwa Less lebih konservatif dalam memulai matematika (menggunakan Amerika/Kanada) di tempat pertama.

@rjgotten

Jangan pernah memperlakukannya sebagai operator pembagian, kecuali dalam konteks matematika yang diketahui.
Di mana konteks matematika yang diketahui dapat/akan diputuskan seperti pada perilaku --strict-math=on saat ini.

Hanya untuk memperjelas, bagian ini (yang saya setujui):

Jangan pernah memperlakukannya sebagai operator pembagian, kecuali dalam konteks matematika yang diketahui.

Sebenarnya memiliki 4 kemungkinan solusi, yang saya tahu Anda tahu, tetapi hanya meringkas ulang untuk utas:

1. Kerjakan semua matematika hanya dalam tanda kurung . Ini tampaknya telah ditolak oleh commons, yang baik-baik saja, meskipun masih tersedia sebagai sakelar opsional ( strictMath ).
2. Kerjakan semua matematika di mana saja, tetapi pembagian hanya dalam tanda kurung.
3. Kerjakan semua matematika di mana saja, tetapi pembagian hanya dalam tanda kurung. Kecuali jika operator divisi dicetak sebagai ./
4. Kerjakan semua matematika di mana saja, tetapi perbaiki matematika agar 12px/4px tidak menghasilkan pembagian. (Perkalian dan pembagian hanya dengan nilai tanpa satuan.) Dengan kata lain, pembagian di mana-mana, tetapi dengan aturan yang jauh lebih konservatif. Dalam kasus di mana itu tidak menyelesaikan masalah, kembali ke melarikan diri. Jadi, bukan solusi yang lengkap, tetapi masih merupakan perbaikan (bisa diperdebatkan) atas situasi saat ini.

Dari perspektif kegunaan, saya suka membuat matematika "lebih pintar" seperti pada #4 . Dari sudut pandang teknik dan pemeliharaan, dan untuk melindungi dari perubahan CSS di masa mendatang, saya menyukai #3 sebagai solusi yang paling kuat.

Namun, saya pikir pada kenyataannya, kita perlu melakukan keduanya #3 DAN #4 untuk memperbaiki calc() . Saat ini, Kurang mengabaikan semua unit saat mengerjakan matematika benar-benar berantakan. 100vh - 12px tidak boleh disentuh oleh Less (tanda kurung atau tidak). Tapi IMO juga tidak 12px/4px (tanda kurung atau tidak), tapi saya mungkin minoritas dalam hal itu.

Jadi, saya tidak melihat ini sebagai masalah "matematika yang bertentangan dengan sintaksis CSS" seperti halnya Kurang terlalu agresif dengan menyelesaikan persamaan matematika sebelum waktunya.

Perkalian dan pembagian hanya dengan nilai tanpa satuan.

itu tidak akan berhasil karena ada hal-hal seperti:

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

dan mereka bukan div.

Namun, saya pikir pada kenyataannya, kita perlu melakukan keduanya #3 DAN #4 untuk memperbaiki calc()

calc() menyebalkan. Ironisnya, ini _mungkin_ paling baik diselesaikan dengan mengimplementasikannya sebagai fungsi Less yang sebenarnya, yang idealnya akan mengambil pohon ekspresi yang diurai dan berusaha menyederhanakan ekspresi. Yaitu: itu harus melakukan pra-komputasi dan menggabungkan komponen yang kompatibel seperti 4px + 12px (atau 4px + @a ketika @a diketahui memiliki nilai piksel) tetapi meninggalkan komponen yang tidak kompatibel, mis. dengan unit yang tidak kompatibel, sendirian.

Misalnya

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

akhirnya harus merender

width : calc(50% - 6px);

(mengulangi diri saya dari https://github.com/less/less.js/issues/1880#issuecomment-345345735)
Dan saya tidak melihat manfaat apa pun dari merekayasa kompiler secara berlebihan untuk mengoptimalkan ekspresi di dalam calc . Jika Anda menulis calc maka Anda baik-baik saja dengan browser untuk melakukan pekerjaan ekspresi panjang apa pun yang Anda miliki di sana. Jadi seperti yang telah disebutkan di atas saya untuk "jangan sentuh apa pun di dalam calc " (= jangan mencoba menjadi lebih pintar daripada yang benar-benar diperlukan) dan biarkan untuk browser ( atau untuk css-minifier sejak , jika saya ingat dengan benar, beberapa dari mereka sudah melakukan pekerjaan yang cukup baik dalam mengoptimalkan subekspresi calc).

"Smart unit behavior mamabo-jambo" mengingatkan saya pada monster min/max (tumpukan kode yang tidak dapat dipelihara dan

PS Segera setelah calc menjadi fungsi yang menerima ekspresi non-aritma-evaluasi (tetap harus demikian) seseorang akan dapat menulis sebuah plugin dan menimpanya dengan pengoptimalan apa pun yang diinginkan.

@rjgotten
Memiliki kompiler yang Kurang 'tahu' tentang itu adalah pendekatan yang pada dasarnya cacat

Saya pikir ini adalah pendekatan yang benar secara fundamental. KURANG adalah kompiler untuk CSS, jadi masuk akal di dunia bahwa KURANG tahu tentang apa yang dikompilasi.

@matthew-dean
Less tidak boleh dan tidak tahu kapan harus "berhenti mengerjakan matematika". Apa yang akan saya katakan adalah bahwa perubahan yang paling penting adalah bahwa Less lebih konservatif dalam memulai matematika (menggunakan Amerika/Kanada) di tempat pertama.

Menarik Anda memikirkannya dari sisi lain, sehingga untuk berbicara. Inilah yang saya usulkan:

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

Apa yang KURANG harus lakukan di sini, jelas bagi saya:

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

Yang menghasilkan:

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

Seharusnya tidak menghitung bagian 50% / 50px dalam ini, karena (1) seharusnya tidak dapat karena unit yang tidak kompatibel dan (2) karena ini sudah cukup jauh untuk nilai background . Jadi di sinilah ia akan "berhenti mengerjakan matematika".

Itulah yang saya maksud dengan KURANG "tahu kapan harus berhenti".

Apakah itu properti yang berbeda seperti ini:

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

Itu harus rusak dengan kesalahan (unit yang tidak kompatibel). Satu keluaran yang mungkin adalah 50% / 15px yang tidak valid untuk properti ini. Hasil lain bisa berupa 5% yang saat ini akan dilakukan, yang salah di segala arah.
Dan:

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

Harus menghasilkan:

padding-left: 10px;

Seperti yang diharapkan. Jadi dalam hal ini, / tidak valid untuk padding-left dan dibawa ke KURANG dan melakukan matematika nya thingy.

@matthew-dean
Sebenarnya memiliki 4 kemungkinan solusi, yang saya tahu Anda tahu, tetapi hanya meringkas ulang untuk utas:

Satu lagi:
5) Gunakan operator \ untuk divisi di KURANG, dan tidak digunakan lagi / . MATLAB memiliki sesuatu seperti ini, dan rasa BASIC tertentu menggunakannya untuk memaksa pembagian bilangan bulat. Jadi menggunakan backslash tidak sepenuhnya tidak pernah terdengar.

/edit
Kami juga dapat melobi untuk memasukkan kunci ÷ pada keybaords dan menggunakannya sebagai operator divisi. Itu yang saya pelajari di sekolah dasar :)

Apa yang Anda sarankan sudah dibahas berkali-kali sebelumnya (jangan ragu untuk melihat utas yang dirujuk di sini). Jadi, inilah komentar kecil-malas:

Gunakan operator \ untuk divisi di KURANG, dan tidak digunakan lagi / .

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

cukup untuk background ... tidak valid untuk padding-left

Temui "Teman-teman, browser saya/polyfill/apa pun yang baru saja menambahkan/memperbarui/memperluas dukungan untuk properti fnord , maukah Anda merilis versi Less baru untuk saya?" masalah.
Temui masalah font .
dll. dll.
Nah, @rjgotten sudah berkomentar di atas mengapa "pengetahuan" semacam itu adalah jalan ke mana-mana.

@seven-fase-max
Backslash hanya saran. Anda mungkin juga menggunakan ? untuk pembagian. Itu tidak masalah. Apa yang saya sarankan, saya kira, adalah untuk tidak menggunakan satu karakter ( / ) yang memiliki arti yang sangat berbeda dan ambigu.

Temui "Teman-teman, browser saya/polyfill/apa pun yang baru saja menambahkan/memperbarui/memperluas dukungan untuk properti fnord , maukah Anda merilis versi Less baru untuk saya?" masalah.

CSS adalah standar yang terdefinisi dengan baik. Anda tidak boleh mendukung apa pun di luar standar. Itu masalah Anda, saya rasa. Anda tidak boleh mendukung properti fnord , karena ini bukan bagian dari standar apa pun. Ketika properti baru yang tidak ditentukan ini terjadi, KURANG mungkin kembali ke perilaku defaultnya, yang bisa berupa saat ini, atau memerlukan tanda kurung, atau apa pun selama tidak ambigu.

Memenuhi masalah font.

Masalah font membuktikan bahwa masalah / telah ada sejak awal KURANG. Bukan hanya ketika background mendapat kemampuan untuk memasukkan nilai untuk ukuran latar atau ketika border-radius muncul. Tbh, dengan menyatakan masalah font, Anda baru saja membuat argumen terbaik melawan diri sendiri :)

Tbh, dengan menyatakan masalah font, Anda baru saja membuat argumen terbaik melawan diri sendiri :)

Saya pikir Anda salah paham tentang sesuatu. Sayalah yang awalnya mengusulkan untuk menghapus total / sebagai operator div. Jadi untuk hal-hal lain saya kira itu masalah yang sama dari Anda tidak memperhatikan apa yang Anda balas.

CSS adalah standar yang terdefinisi dengan baik.

Jika Anda akan tetap berpegang pada bagian spesifikasi yang telah mencapai kematangan penuh di level TR, mungkin.
Jika tidak? Tidak. Ada spesifikasi satelit dari 'modul' CSS baru dan revisi modul yang ada dengan tambahan baru di dalamnya yang muncul setiap bulan, jika tidak setiap minggu.

@seven-fase-max

itu tidak akan berhasil karena ada hal-hal seperti: font: small-caps bold 24px/3 ...

Tidak, saya mengerti. Maksud saya persis seperti itu: hanya div/perkalian tanpa unit mengurangi masalah tetapi tidak menyelesaikan masalah.

Dan saya pikir secara umum saran Anda tentang ./ untuk semua divisi tampaknya masih cukup logis.

@thany Daripada menanggapi semua contoh spesifik, saya akan mengatakan bahwa secara umum, upaya untuk membuat matematika Kurang lebih pintar hanya akan menendang bola ke garis yard yang berbeda. Masih masalah yang sama, hanya di tempat yang berbeda. Seperti yang dikatakan @seven-phases-max, tidak ada yang Anda sarankan yang belum dibahas.

Dan saya tidak melihat manfaat apa pun dari merekayasa kompiler secara berlebihan untuk mengoptimalkan ekspresi di dalam calc. Jika Anda menulis calc maka Anda boleh menggunakan browser untuk melakukan pekerjaan apa pun ekspresi panjang yang Anda miliki di sana. Jadi seperti yang telah disebutkan di atas saya untuk "jangan sentuh apa pun di dalam calc" (= jangan mencoba menjadi lebih pintar daripada yang benar-benar diperlukan) dan biarkan untuk browser (atau untuk css-minifier karena, jika saya ingat dengan benar , beberapa dari mereka sudah melakukan pekerjaan yang cukup baik dalam mengoptimalkan subekspresi calc).

Saya setuju dengan ini sepenuhnya. Kami akan membunuh 99% masalah baru terkait matematika jika kami hanya memasukkan calc() daftar putih. Sementara saya telah menyarankan beberapa cara agar Less bisa lebih pintar mengerjakan matematika untuk JUGA menghindari masalah calc() (yang mungkin seharusnya), saya minta maaf jika itu ditafsirkan sebagai argumen yang menentang ide ini. Saya mendukung ini juga.

Satu-satunya peringatan (seperti yang dibahas di sini/di tempat lain) adalah bahwa pengembang pasti ingin menggunakan variabel dalam calc() , jadi kita harus berhati-hati untuk memastikan bahwa kita terus menukar vars, tetapi jangan lakukan matematika. Saya tidak yakin seberapa menantangnya itu. Jika kami berhasil melakukannya, saya akan mendukung perubahan dalam penanganan calc() hari ini.

@thany

Masalah font membuktikan bahwa / masalah telah ada sejak awal mutlak KURANG.

Ini mungkin benar dan merupakan poin yang adil, tetapi ada banyak solusi yang sesuai dan pada saat itu belum tentu merupakan praktik standar untuk menggunakan steno properti font . Ini benar-benar karena beberapa latar belakang dan calc() tiba setelah Kurang dimulai yang membuat ini lebih menjadi masalah, dan sekarang sintaks CSS Grid berarti sekarang ada banyak konflik di mana awalnya tidak ada dalam istilah praktis sehari-hari.

Kebetulan, ini adalah cara Sass menyelesaikan masalah, diilustrasikan oleh contoh ini:

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
}

Ini bukan satu-ke-satu, karena Anda dapat melakukan matematika (saat ini) dalam argumen ke Lebih sedikit fungsi, DAN Lebih sedikit fungsi dapat mengembalikan nilai piksel (jadi Lebih sedikit dapat melakukan font: print10px()/8px , secara teoritis? tidak?), jadi saya Saya hanya menempelkannya sebagai ilustrasi, bukan sebagai saran apa pun. Hanya menarik bagaimana mereka mendekati masalah.

Secara pribadi, saya pikir membuat pengembang mencoba mengingat dalam kasus mana matematika akan terjadi berdasarkan keberadaan ekspresi ajaib adalah semacam pembuatan gila (seperti pra-penangguhan oleh + ?), tetapi untuk masing-masing milik mereka sendiri .

Secara pribadi, saya pikir membuat pengembang mencoba mengingat dalam kasus mana matematika akan terjadi berdasarkan keberadaan ekspresi ajaib adalah hal yang gila.

+1

_{Bahkan tidak menghitung bahwa "solusi" tidak menyelesaikan masalah yang dibahas di sini selain yang sudah dilakukan lessc --sm . Dan hasil yang berbeda untuk 1/2 dan $var/2 adalah fenomena yang sangat brilian ... ~kebodohan~ "Selamat men-debug, pecundang!"}

@matthew-dean
Kebetulan, ini adalah cara Sass menyelesaikan masalah, diilustrasikan oleh contoh ini:

Itu solusi yang brilian tanpa menggunakan operator yang berbeda.
Jika ekspresi tersebut mungkin adalah CSS yang valid, biarkan saja.

Secara pribadi, saya pikir membuat pengembang mencoba mengingat dalam kasus mana matematika akan terjadi berdasarkan keberadaan ekspresi ajaib adalah hal yang gila.

Tidak setuju. Ini adalah seperangkat aturan sederhana, tidak berbeda dari seperangkat aturan (gila atau tidak) lainnya yang perlu Anda ingat.

Ada beberapa kasus tepi di mana matematika terjadi tanpa maksud, tetapi kemudian Anda cukup menerapkan tanda kurung dan selesai.

Bahkan tidak termasuk bahwa "solusi" tidak menyelesaikan masalah yang dibahas di sini di luar apa yang sudah dilakukan lessc --sm. Mengapa saya akan menulis 0 + 1/2 alih-alih (1/2) ketika yang saya inginkan hanyalah sebuah divisi? Dan hasil yang berbeda untuk 1/2 dan $var/2 benar-benar brilian ... kebodohan "Selamat men-debug, pecundang!" pesan.

Ha, ya, ini.

@thany

Itu solusi yang brilian tanpa menggunakan operator yang berbeda.
Jika ekspresi tersebut mungkin adalah CSS yang valid, biarkan saja.

Tidak masuk ke gulma, tetapi itu tidak akan berhasil untuk Less, karena alasan sintaksis dan juga konsistensi bahasa. Ini mungkin brilian untuk Sass, yang menurut saya bisa diperdebatkan, tapi saya tidak terlibat secara pribadi dengan proyek itu dari perspektif desain, jadi siapa bilang. Yang saya tahu adalah bahwa opsi di atas meja adalah tempat terbaik untuk memulai, dan saya yakin jika Anda menghabiskan banyak waktu melalui beberapa utas pesan yang terkait dengan masalah ini dan menghabiskan waktu dengan bahasa, Anda akan datang ke kesimpulan yang sama.

Satu pengamatan yang tidak dapat kami hindari: jika Anda mengimpor Vanilla CSS yang valid, outputnya harus identik secara fungsional. Jadi satu-satunya kesimpulan yang dapat saya tarik adalah bahwa KURANG tidak boleh menyentuh ekspresi yang mungkin merupakan CSS yang valid. Bagaimana ini dilakukan, bukan terserah saya. Tetapi faktanya tetap bahwa mengimpor vanilla CSS tidak dapat diandalkan, sebagian besar karena KURANG mengeksekusi divisi yang terlalu bersemangat.

Mengimpor vanilla CSS di Sass bekerja hampir tanpa cacat, karena seperti yang dikatakan, Sass membiarkan operator / sendirian jika tidak menunjukkan kepada kompiler untuk pergi dan melakukan sesuatu, menurut beberapa aturan sintaks sederhana. Aturan sintaks ini menjelaskan cara untuk memaksa pembagian yang tidak dapat terjadi di CSS Vanilla yang valid, dan itulah mengapa itu brilian.

Anda masih berdebat dengan imajinasi Anda sendiri dan bukan dengan apa yang mereka katakan kepada Anda. Jawab pertanyaan sederhana: "Bagaimana 0 + 1/2 bisa lebih baik dari (1/2) ?". Jika kompatibilitas 100%-CSS adalah satu-satunya hal yang Anda pedulikan, atur -sm dan lupakan utas ini.

Satu pengamatan yang tidak dapat kami hindari: jika Anda mengimpor Vanilla CSS yang valid, outputnya harus identik secara fungsional. Jadi satu-satunya kesimpulan yang dapat saya tarik adalah bahwa KURANG tidak boleh menyentuh ekspresi yang mungkin merupakan CSS yang valid. Bagaimana ini dilakukan, bukan terserah saya. Tetapi faktanya tetap bahwa mengimpor vanilla CSS tidak dapat diandalkan, sebagian besar karena KURANG mengeksekusi divisi yang terlalu bersemangat.

Bagian ini pada dasarnya saya setujui, dan saya pikir Anda akan menemukan banyak kesepakatan di utas ini tentang hal itu. Sebagian besar ketidaksepakatan adalah seputar solusi, dengan masing-masing solusi memiliki berbagai efek samping.

Saya akan setuju dengan menjadikan perubahan yang melanggar ini sebagai prioritas:

1. matematika di luar tanda kurung membutuhkan ./ alih-alih / telanjang. 12px./10px masih terlihat sedikit aneh.

@seven-phases-max - Saya ingin mengunjungi kembali garis miring terbalik. Terkait dengan ini, saya tahu Anda menyebutkan https://github.com/less/less.js/issues/1872#issuecomment -35245890 , tapi saya tidak melihat konflik langsung, karena pengidentifikasi itu tidak dan saya pikir tidak bisa bagian dari ekspresi matematika. Atau aku salah? Saya kira mungkin untuk membuat kasus teoretis seperti nama fungsi dengan karakter yang lolos sebagai bagian dari nama, tetapi itu lebih seperti latihan intelektual daripada kasus dunia nyata. Pemilih yang lolos, ya, itu biasanya digunakan karena berbagai alasan, tetapi dalam nilai properti, sepertinya tidak mungkin, atau, dalam kasus tepi, oke untuk memecahkan/menyelesaikan dengan solusi historis (lepaskan saja teks ini).

Bisakah kita mengeksplorasi lebih jauh bahwa menggunakan satu garis miring terbalik untuk pembagian akan menyebabkan konflik di dunia nyata? Naluri saya adalah bahwa \ kurang bermasalah daripada situasi saat ini di sekitar / , dan lebih ramah pengembang daripada ./ . Jika kami melakukan penelitian dan menemukan itu layak, maka kami dapat membuat perubahan besar untuk menggunakannya di mana-mana, alih-alih pengalihan konteks yang mengizinkan / dalam tanda kurung. Dan kemudian kami dapat mendukung / dengan sakelar lawas.

1. (prioritas kedua) calc() menjadi kasus khusus sehingga dapat melakukan penggantian variabel tetapi tidak akan mengevaluasi ekspresi matematika apa pun

Bisakah kita mengeksplorasi lebih jauh bahwa menggunakan satu garis miring terbalik untuk pembagian akan menyebabkan konflik di dunia nyata?

Nah, masalahnya \anycharacter adalah CSS yang valid dan memiliki arti tersendiri. Tentu, Anda hampir tidak menemukan kode seperti itu dalam proyek nyata (kecuali mungkin peretasan seperti \9 -seperti), tapi... apakah kita ingin memberi makan singa itu? Memperbaiki satu "uh-oh, CSS saya yang 100% valid tidak dapat dikompilasi" dengan memperkenalkan "uh-oh" lain dengan suara yang sama terdengar agak aneh :)

Adapun calc Saya kira kami memiliki konsensus sejak awal - jadi pada dasarnya hanya menunggu sukarelawan untuk mengimplementasikannya (saya memperkirakan perbaikan cepat dilakukan hanya dalam 5-6 baris kode baru - jadi ini benar-benar hanya tentang seorang pria pemberani untuk melakukan ini - detail implementasi kecil mungkin berbeda tetapi saya pikir mereka baik-baik saja untuk diputuskan dalam proses).

Nah, masalahnya \anycharacter adalah CSS yang valid dan memiliki arti tersendiri. Tentu, Anda hampir tidak menemukan kode seperti itu di proyek nyata (kecuali mungkin peretasan seperti \9), tapi... apakah kita ingin memberi makan singa itu? Memperbaiki satu "uh-oh, CSS saya yang 100% valid tidak dapat dikompilasi" dengan memperkenalkan "uh-oh" lain dengan suara yang sama terdengar agak aneh :)

Saya mendengar Anda, ini adalah kemungkinan trade-off. Dan ya saya tahu bahwa \anycharacter adalah CSS yang valid. Saya kira saya bertanya-tanya apakah itu set trade-off yang lebih baik. Hanya saja ketika saya menulis 12px./10px rasanya aneh, secara sintaksis. Saya merasa Less secara sintaksis telah mencoba menggunakan kembali CSS sebanyak mungkin tanpa menimbulkan konflik.

Seperti, ./ memberikan kejelasan sintaks dan sepenuhnya menghindari konflik, tetapi begitu juga menerapkan tanda kurung di mana-mana untuk matematika, itulah sebabnya saya mendukungnya, tetapi ada reaksi balik, dan saya khawatir tentang itu di sini. Jadi apakah ada kasus yang sah di mana kita akan salah mengira 10px\10 sebagai maksud pengembang untuk melarikan diri \10 ? Saya tahu itu teori yang sulit, dan maksud Anda mungkin adalah bahwa kita tidak benar-benar tahu.....Ini pertanyaan yang rumit, dan menambahkan sintaks baru selalu penuh, terutama dengan Less karena kita tidak tahu semua CSS di dalamnya. CSS liar atau masa depan.

Adapun calc, saya kira kami memiliki konsensus sejak awal - jadi pada dasarnya hanya menunggu sukarelawan untuk mengimplementasikannya (saya memperkirakan perbaikan cepat dilakukan hanya dalam 5-6 baris kode baru - jadi ini benar-benar hanya sekitar satu pria pemberani untuk melakukan ini - detail implementasi kecil mungkin berbeda tetapi saya pikir mereka baik-baik saja untuk diputuskan dalam proses).

Bagus! Haruskah kita melacaknya secara terpisah untuk meningkatkan visibilitas?

@seven-fase-max:

Tentu, Anda hampir tidak menemukan kode seperti itu di proyek nyata (kecuali mungkin peretasan seperti \9 -seperti)

Benar . Oh "orang barat" yang brengsek itu... :)

@seven-fase-max
Jawab pertanyaan sederhana: "Bagaimana 0 + 1/2 bisa lebih baik dari (1/2)?"

Saya tidak melihat ke mana Anda akan pergi dengan itu. (1/2) harus dieksekusi oleh KURANG karena tidak mungkin CSS yang valid, jadi itu harus berarti KURANG. 0 + 1/2 seharusnya menjadi 1/2 mana LESS mengeksekusi bagian 0 + 1 karena itu adalah bagian yang tidak dapat menjadi CSS yang valid. Bagian 1/2 bisa jadi valid, jadi lebih baik tidak menyentuhnya.

@thany
Oke, sekarang sadari (1/2) berfungsi seperti yang Anda harapkan di Less dan Sass..
Dan 0 + 1/2 (serta 1 * 1/2 dll.) adalah bagian dari solusi yang Anda sebut brilian di atas dan hasilnya adalah 0.5 .
Masih tidak tahu apa yang terjadi di sini?
Baca kembali semuanya (mulai dari posting pertama Anda) di atas sekali lagi dan coba jawab sendiri "Apa sebenarnya yang saya keluhkan?".

@seven-fase-max
Dan 0 + 1/2 (serta 1 * 1/2 dll.) adalah bagian dari solusi yang Anda sebut brilian di atas dan hasilnya adalah 0,5.

Tidak, solusinya adalah 1/2 bukan 0.5 , karena 1/2 mungkin merupakan CSS yang valid. Anda sepertinya tidak ingin KURANG tahu kapan garis miring valid, jadi anggap selalu begitu. Oleh karena itu 1/2 adalah satu-satunya hasil logis. Dengan cara yang sama, 2 * 1/2 akan menghasilkan 2/2 , karena * akan membuat CSS tidak valid.

Masih tidak tahu apa yang terjadi di sini?

Saya sangat jelas apa yang terjadi di sini. KURANG mengeksekusi pembagian matematika dengan penuh semangat dan mengabaikan unit secara membabi buta.

Baca ulang semuanya (mulai dari posting pertama Anda) di atas sekali lagi dan coba jawab sendiri "Apa sebenarnya yang saya keluhkan?".

Tidak perlu serangan pribadi.

KURANG mengeksekusi pembagian matematika dengan penuh semangat dan mengabaikan unit secara membabi buta.

Jadi ini yang kamu keluhkan, kan?

Tidak perlu serangan pribadi.

Jadi apa yang harus saya lakukan? Mengulangi dua posting asli lagi dan lagi (dan lagi)? Sampai jelas bagi Anda:
@komunitas :

gunakan opsi -sm

@thany :

maka itu harus aktif secara default.

@seven-fase-max:

Tidak mungkin karena ini akan segera menghancurkan jutaan proyek di luar sana. Jadi, jika Anda memperlakukan perilaku default sebagai masalah, cukup atur opsi yang didokumentasikan dan selesai.

Jadi Anda mengulangi "seharusnya", "seharusnya", "seharusnya" mengharapkan apa? Tebak bagi kami lebih mudah untuk menjawab hanya "Tidak, seharusnya tidak" daripada membuang waktu kami mencoba menjelaskan secara rinci mengapa apa yang Anda sarankan tidak akan berhasil atau tidak masuk akal secara umum (penjelasan yang Anda juga tidak ingin mengerti atau tidak bisa).

Jadi tentang apa utas ini? Ini tentang "menyadari bahwa sementara perubahan akhirnya membuat " -sm -seperti perilaku default tidak dapat dihindari, kita harus menyediakan fasilitas untuk aritmatika yang lebih nyaman selain yang mengerikan: margin: (1/2) (3/4) (5/6) (7/8); untuk mereka yang banyak menggunakan aritmatika".
Anda memposting di sini menyarankan sesuatu yang tidak jauh lebih baik daripada (atau melakukan persis sama dengan) perilaku -sm sudah ada atau berdebat dengan sesuatu yang tidak mungkin dari awal (seperti there ). Dengan kata lain, hanya suara acak .

@seven-phases-max @thany Mari kita turunkan suhunya. Ada pendapat yang kuat di sekitar.

Saya pikir kebanyakan orang berada di halaman yang sama di sekitar keduanya, idealnya tidak ditafsirkan oleh Less sebagai ekspresi matematika:

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

Jadi, sebagian besar ada kesepakatan tentang poin-poin itu, dan sebagian besar argumen seputar solusi yang mungkin. Masalah calc() sepertinya memiliki konsensus yang cukup untuk bergerak maju. Pada dasarnya: jangan sentuh calc, dan perlakukan vars di calc() seperti interpolasi string. Kurang lebih seperti itu cara Sass melakukannya, meskipun memerlukan sintaks interpolasi di calc() , yang menurut saya tidak kita perlukan.

Solusi untuk bagian font menjadi jauh lebih rumit dan solusi utamanya adalah:

1. Memerlukan orang tua untuk semuanya secara default (percobaan pertama - hampir diterapkan, tetapi komunitas ditolak)
2. Balikkan sakelar strictMath (yang ditambahkan alih-alih menjadikannya default, dan saran @seven-phases-max) dan kemudian secara eksplisit lakukan semua perhitungan Anda. Ini, secara teknis, merupakan solusi yang mungkin bagi kebanyakan orang saat ini, tetapi.... pertanyaannya sering muncul dan kami tahu, secara psikologis, bahwa seseorang yang baru mengenal sistem apa pun kemungkinan tetap memiliki default, jadi ini bermasalah. Dan tidak setiap developer dapat mengubah pengaturan build mereka, terutama dalam tim.
3. Pada dasarnya mengubah operator divisi di Less. Pesaing utama di utas adalah ./ , yang berfungsi tetapi agak aneh untuk dilihat. \ tidak diketahui pada saat ini tanpa penelitian. Bisa bekerja, bisa menyebabkan konflik yang tidak diketahui dengan melarikan diri. Sintaksnya lebih bersih, pada (berpotensi, tetapi tidak diketahui) risiko yang lebih tinggi. Jika seseorang meluangkan waktu untuk mendemonstrasikan bahwa ini TIDAK akan menyebabkan konflik yaitu memberikan contoh melarikan diri dan matematika bercampur dengan cara pengurai dapat dengan jelas membedakan keduanya, maka itu masih kemungkinan. Jadi hanya butuh kerja. @thany , jika Anda atau orang lain adalah penggemar ini, maka ini adalah pekerjaan yang diperlukan. Hal terakhir yang kami inginkan hanyalah memindahkan jeda ke tempat lain.

Saya pikir, untuk menyederhanakan utas ini, kita harus, dari sini, fokus HANYA pada #3 . Saya memposting contoh Sass sebagian besar sebagai rasa ingin tahu, tetapi saya tidak percaya solusi itu baik atau sepenuhnya menyelesaikan masalah, dan mereka secara konseptual tidak sesuai dengan Less. Berdebat tentang validitas membutuhkan 0 + 1/2 tidak akan membawa kita kemana-mana.

Jadi, dengan solusi yang baik di atas meja untuk calc() , yang memberi kita 50% dari jalan ke sana untuk sebagian besar masalah yang diposting, saya akan merekomendasikan hanya berfokus pada pertanyaan ini dalam jangka pendek:

Jika operator divisi Less harus diubah, apa yang harus diubah?

• ./ - apakah ini canggung seperti yang saya rasakan, atau apakah orang berpikir itu baik-baik saja?
• \ - tanpa penelitian dan bukti, dan kode semu untuk diikuti oleh parser, ini tidak akan bergerak maju. Saya pribadi lebih suka, jika terbukti aman.
• Pengganti lainnya?

Sejujurnya, jika kita mengubah calc() dan mengubah / , saya pikir kita akan menghilangkan 99% kebisingan seputar matematika di Less.

Hai semua, saya memperbaiki calc() - https://github.com/less/less.js/pull/3162

Saya agak heran ketika saya menemukan solusi yang bekerja tanpa banyak kode tambahan. Pada dasarnya, kami sudah memiliki kode untuk sakelar strictMath , dan memeriksa ekspresi untuk tidak mengevaluasi matematika jika itu di luar parens, jadi saya hanya menambahkan sakelar tambahan pada panggilan untuk mematikan matematika saat mengevaluasi calc() argumen, dan kemudian kembali. Kami sudah memiliki semua bagian untuk meninggalkan matematika saja, tetapi masih mengganti vars. Hah.

Lihat https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d dan https://github.com/less/less.js/pull/3162/files#diff -4e6962711823c96903a91fff84983bab6fff84983bab6

Apakah tes cukup?

@matthew-dean :kopi:

Apakah tes cukup?

per komentar di PR tambahkan silakan tes seperti:

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

Dan komentar kecil: perbaikan ini jelas menimbulkan masalah yang sama seperti pada #1627, yaitu

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

Tetapi untuk calc tidak apa-apa saya kira (setelah semua tidak ada cara sederhana lain untuk memperbaikinya tanpa pengulangan besar dari konsep lazy-eval). Jadi saya pikir ini hanya masalah menempatkan pemberitahuan ke dalam dokumen untuk mengingat lazy-eval saat menggunakan vars dalam calc .

Dan komentar kecil: perbaikan ini jelas menimbulkan masalah yang sama seperti pada #1627

Tangkapan yang bagus!

Mengganti konteks properti mathOn per panggilan menyelesaikan ini, mirip dengan komentar Anda di PR. Saya telah menambahkan tes untuk float(1 + .1) yang lolos!

Mengganti properti konteks mathOn per panggilan menyelesaikan ini, mirip dengan komentar Anda di PR. Saya telah >menambahkan tes untuk float(1 + .1) yang lolos!

:) Tidak, kesalahan "lantai" harus ada saat -sm: off . Lihat komentar saya yang lebih baru di PR.
Pemulihan hanya menangani hal-hal seperti 1 + 2 calc(3 + 4) 5 + 6 -seperti.

:) Tidak, kesalahan "lantai" harus ada saat -sm: mati.

Mengapa? Fungsi apa pun di dalam calc() harus berupa fungsi Less. Bahkan jika tidak, tidak ada fungsi CSS-asli di dalam calc() yang saya ketahui dapat mengambil ekspresi matematika mentah. Hasil yang diharapkan adalah mengevaluasi fungsi vars dan Less, tetapi membiarkan fungsi mentah di dalam calc() saja.

Catatan tambahan: Saya melakukan eksperimen cabang untuk mengalihkan / ke \ sebagai operator divisi di Less. Sudah ada banyak tes untuk melarikan diri (dan saya menambahkan lebih banyak, ke alamat: #3160), dan semuanya masih berfungsi dengan baik, dan matematika berfungsi dengan baik dengan operator yang diaktifkan. Saya tidak melihat adanya konflik yang melekat. Cabang ada di sini di garpu saya: https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

Re: fungsi bersarang

Untuk ini:

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

Sebagai pengembang, hasil yang diharapkan adalah:

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

Itulah yang terjadi sekarang (dengan perubahan ini). Seharusnya tidak melempar kesalahan.

@matthew-dean
Tidak, cara Anda menulisnya, ini:

foo: unit(1/2, px);

dengan -sm:on akan dikompilasi ke:

foo: .5px;

^- salah.
Sama untuk fungsi bersarang. Selain itu, fakta bahwa sebagian besar fungsi biasanya tidak dapat menggunakan ekspresi aritmatika sebagai argumen bukanlah alasan untuk melanggar -sm: on ;
Jadi di bawah -sm: on kedua baris:

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

harus melempar kesalahan (dan inilah yang rusak di komit).

Apa yang kamu bicarakan?

unit(1/2, px) dengan -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%) dengan -sm:on

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

Periksa cabang. Cobalah.

Satu hal yang mungkin lebih membantu dengan meninjau kode adalah jika Anda tidak yakin apakah sesuatu akan menghasilkan keluaran yang salah, harap verifikasi. Atau minta saya untuk mencoba input tertentu untuk memverifikasi bahwa itu berfungsi seperti yang diharapkan. Atau ajukan pertanyaan jika Anda tidak yakin bagaimana/mengapa cara kerjanya. Menyebutnya salah tanpa mengetahui apakah itu tidak membantu.

Permintaan maafku. Saya kira saya melewatkan kontrol tidak langsung dari bagian ini.

Periksa cabang. Cobalah

Aku tidak bisa, maaf.

Permintaan maafku. Saya kira saya melewatkan kontrol tidak langsung dari bagian ini.

Jangan khawatir. Dengan itu, apakah itu terlihat berfungsi seperti yang Anda harapkan?

Dengan itu, apakah itu terlihat berfungsi seperti yang Anda harapkan?

Ya, sejauh ini saya tidak bisa membayangkan hal-hal mencurigakan lainnya di sana.

@matthew-dean
Pada dasarnya mengubah operator divisi di Less. Pesaing utama di utas adalah ./, yang berfungsi tetapi agak aneh untuk dilihat. \ tidak diketahui pada saat ini tanpa penelitian [...] @thany , jika Anda atau orang lain adalah penggemar ini, maka ini adalah pekerjaan yang diperlukan. Hal terakhir yang kami inginkan hanyalah memindahkan jeda ke tempat lain.

Tidak sama sekali sebenarnya. Saya menyarankan operator \ sebagai upaya terakhir setelah tidak berhasil, mencoba membuat KURANG hanya mengerjakan matematikanya sendiri. Jika dibutuhkan operator pembagian baru... Nah, calc() juga bisa melakukan penjumlahan, pengurangan, dan perkalian. Operator baru untuk itu? Saya pikir itu tidak praktis. Operator divisi baru mungkin menjadi solusi untuk hal-hal seperti font, latar belakang, dan radius batas, tetapi itu bukan solusi untuk matematika CSS.

Saya masih berpikir solusi sebenarnya adalah KURANG tahu tentang konteks. Seharusnya (ya, ini dia lagi dengan "harus", kata lain apa yang harus saya gunakan?...) tahu bahwa calc() adalah fungsi CSS dan seharusnya hanya mengevaluasi matematika yang tidak dapat dilakukan CSS . Tetapi floor() tidak ada di CSS, sehingga harus dievaluasi (seluruhnya) agar tidak mengeluarkan CSS yang tidak valid. Saya pikir ini disebutkan sebelumnya, dalam kata-kata yang berbeda.

Saya masih berpikir solusi sebenarnya adalah KURANG tahu tentang konteks. Seharusnya (ya, ini saya pergi lagi dengan "harus", kata lain apa yang harus saya gunakan?...) tahu bahwa calc() adalah fungsi CSS dan seharusnya hanya mengevaluasi matematika yang tidak bisa dilakukan CSS. Tetapi floor() tidak ada di CSS, sehingga harus dievaluasi (seluruhnya) agar tidak mengeluarkan CSS yang tidak valid. Saya pikir ini disebutkan sebelumnya, dalam kata-kata yang berbeda.

Cukup adil untuk: \ , tetapi sejauh konteksnya, berdasarkan posting Anda yang lain, saya dapat menjamin itu adalah masalah yang jauh lebih kompleks daripada yang Anda pikirkan. Anda benar-benar harus merebusnya menjadi:

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

Jika Anda ingin benar-benar meninggalkan / sebagai operator divisi, untuk meniru calc() , dan tidak membuatnya ambigu, maka Anda benar-benar perlu memastikan bahwa / ada di tanda kurung (selain pengecualian calc() ). Itu akan memberikan konteks yang dapat diprediksi.

Saran itu di awal utas ini juga masih merupakan kemungkinan, dan mendapat dukungan kuat. Pada dasarnya, bahwa pengaturan default adalah bahwa semua matematika didukung di luar tanda kurung KECUALI pembagian (dan lagi, kecuali calc() , sekarang menjadi kasus dari 3.0+). Mungkin itu adalah cara untuk pergi. Itu akan memungkinkan:

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

Masalahnya, hasil untuk 10px+15px/1.5 mungkin masih sulit untuk dipahami oleh pengembang, dengan ekspresi yang tampaknya "dievaluasi setengah" kecuali dalam tanda kurung. Jika kami melanjutkan dan mengaktifkan matematika ketat secara default, itu mungkin akan baik-baik saja. Ini bahkan kurang ambigu. [mengangkat bahu] Bagaimanapun, membungkus matematika dalam beberapa jenis konteks ADALAH cara untuk menghilangkan ambiguitas, dan satu-satunya cara untuk pembagian selain mengubah operator pembagian.

Masyarakat pada dasarnya harus memutuskan arahnya. Ada opsi yang layak di utas ini. Masing-masing memiliki kekurangan. Masing-masing memiliki poin rasa sakit. Tidak ada yang akan memiliki konsensus penuh. Tapi IMO salah satu dari mereka lebih baik dari skenario saat ini. Hanya harus menelan pil itu.

Panggilan terakhir untuk sebuah keputusan

Jadi dalam upaya untuk mengerjakan hal yang mustahil, saya ingin mengusulkan agar kita melakukan ini (mengacu kembali ke komentar dari 3 tahun yang lalu.)

Berikan --strict-math 3 pengaturan

1. mati
2. divisi
3. ketat (alias on untuk back-compat)

Untuk menyelesaikan perdebatan, izinkan sakelar --strict-math=division melakukan hal berikut:

1. Jangan melakukan pembagian hanya dengan karakter / luar tanda kurung. Misal border-radius: 55px / 25px; --> no-math (ya, itu CSS yang valid)
2. Izinkan pembagian dengan dua metode berbeda:
   sebuah. . awalan - border-radius: 55px ./ 25px;
   B. tanda kurung - border-radius: (55px / 25px);
3. Kedua formulir valid dalam tanda kurung - misalnya border-radius: (55px ./ 25px); akan valid

Jadi, sebagai pengembang, jika Anda merasa satu versi bukan pilihan Anda, Anda bisa menggunakan versi lainnya. Beberapa mungkin memilih untuk tidak menggunakan tanda kurung; beberapa mungkin memilih untuk tidak menggunakan operator divisi yang dimodifikasi. Sesuatu untuk semuanya. Dan tidak ada lagi kejutan yang tidak menyenangkan bagi mereka yang baru menggunakan Less menggunakan apa yang sekarang menjadi sintaks yang tersebar luas di CSS, dengan / digunakan di font , background , border-radius , @media kueri, properti CSS Grid, dan mungkin lebih banyak lagi di masa mendatang.

Langkah selanjutnya

Saya merekomendasikan ini masuk ke PR sebagai opsi, dan kemudian, seperti yang dibahas, dialihkan sebagai default untuk versi utama di masa mendatang

@matthew-dean

Yaitu periode bertindak seperti kebalikan dari urutan pelarian?
Bukan ide yang buruk, sungguh...

Dan semua hal dipertimbangkan, _mungkin_ salah satu solusi yang paling bersih.

@rjgotten Mulai di sini: https://github.com/matthew-dean/less.js/tree/strict-math-division

Saya masih mendapatkan kesalahan aneh salah satu tes, di mana tampaknya mengubah salah satu node dimensi menjadi node operasi (dan kemudian melempar kesalahan karena tidak dapat melakukan operasi pada node operasi. Tidak' t tampaknya menjadi masalah penguraian karena tes lain tidak berjalan di bawah strictMath: division berfungsi dengan baik. Ingin memeriksanya dan melihat apakah Anda dapat membantu?

Apa yang ingin saya lakukan adalah menutup masalah ini dan membuat masalah baru yang menangani pertanyaan matematika yang tersisa. Secara khusus:

1. Menangani divisi, dan fitur strictMath: 'division' .
2. Menangani matematika unit campuran. Lihat: https://github.com/less/less.js/issues/3047