Less.js: Kode CSS Bersyarat

pergi ke http://www.lesscss.org/ dan cari penjaga.

untuk menghindari keharusan menggunakan mixin, lihat permintaan fitur untuk mengizinkan penjaga di css apa pun.

Ya, saya tahu itu, tetapi jika kami menulis KURANG besar, kami harus menulis dan mengelola ratusan .mixin
Saya tidak berpikir mixin memecahkan masalah ini. Bahkan mixin akan mendapatkan banyak kekuatan dengan fitur ini.
Kurang CSS hampir memiliki semua fitur yang dimiliki beberapa bahasa pemrograman lalu mengapa tidak?

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

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

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

Saya akan menambahkan +1 besar untuk fitur ini yang benar-benar saya lewatkan. Mempertahankan penjaga dengan basis kode besar benar-benar mimpi buruk. Ini benar-benar akan membuat segalanya jauh lebih mudah...

Kami bahkan dapat menambahkan pernyataan sakelar ..

@lukeapage bisakah Anda membuka kembali masalah ini. Saya pikir kita harus mendiskusikan masalah/fitur ini

KURANG bukan bahasa scripting. Sintaks/gayanya menyerupai CSS.

KURANG dimaksudkan untuk menjadi deklaratif, artinya seharusnya tidak mampu situasi kompleks dengan logika percabangan, loop, dll.

@pierresforge apakah Anda punya contoh di mana penjaga tidak mencukupi?

dan di mana itu tidak akan diselesaikan dengan dapat memiliki penjaga di pemilih mana pun?

diskusi terbuka .. jika Anda dapat membujuk saya (atau anggota tim inti lainnya) mereka diperlukan maka saya akan membuka kembali masalah .. tetapi percakapan telah dilakukan sebelumnya dan banyak waktu telah dihabiskan untuk itu .

Kalimat dari http://lesscss.org/
"LESS memperluas CSS dengan perilaku dinamis seperti variabel, mixin, operasi, dan fungsi."

Ya KURANG bukan bahasa scripting, tetapi masih memiliki fitur seperti variabel, fungsi & operasi.
Apa yang hilang adalah logika kondisional.

Saya pikir CSS Media Query tidak lain adalah logika kondisional.

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

Jika CSS dapat memiliki logika kondisional seperti penjaga. jadi apa bedanya. Penjaga hanya memperluasnya ke mixin.
Penjaga hanya mengizinkan kondisi di luar blok kode CSS dan tidak di dalam blok kode.
Silakan lihat https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 misalnya, penjaga tidak dapat membantu dengan persyaratan seperti itu..

Bahkan HTML memiliki logika bersyarat, ya dan itu adalah bahasa markup bukan bahasa skrip.

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

@lukeapage terima kasih..

Penjaga analog dengan apa yang dilakukan kueri media. Perhatikan bahwa dalam CSS biasa Anda tidak dapat membuat kueri media di dalam pemilih; Anda hanya dapat meletakkannya di root dokumen.

Tidak, saya tidak punya contoh di mana penjaga tidak cukup. Namun, ada banyak tempat di mana penjaga tidak benar-benar terbaik untuk perawatan.

Sebuah contoh:

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

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

menurut saya lebih ringkas dan cukup jelas (kebanyakan dalam kasus di mana tidak ada gunanya membuat kode dapat digunakan kembali, karena algoritme bergantung pada banyak faktor) daripada:

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

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

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

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

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

Saya setuju ini dapat didiskusikan, tetapi ini akan menjadi tambahan yang cukup bagus, jika tidak melibatkan banyak perubahan inti. Ini memungkinkan untuk menyatukan sebagian besar aturan untuk diterapkan pada satu elemen tanpa memerlukan penambahan mixin.

Situasi seperti ini adalah mengapa saya menulis fungsi kontras - ini bertindak sebagai semacam operasi bersyarat yang tidak tersedia, dan itu jauh lebih rapi daripada menggunakan pelindung, seperti yang Anda katakan. Saya kira kita bisa mengimplementasikan semacam fungsi generik yang bertindak sebagai semacam pemilih, daripada menambahkan sintaks untuk kondisi.

@Soviut Devil's advokat - Dalam KURANG, Anda benar-benar BISA menempatkan kueri media Anda di dalam pemilih, yang seringkali cukup berguna.

Saya telah menentang jika, karena mulai membuat kompleksitas kode Anda meningkat secara eksponensial, dan KURANG dirancang untuk menjadi sederhana dan lugas. Saat ini, ada beberapa dorongan untuk menstabilkan bahasa daripada menambahkan fitur baru.

Namun.... pendukung iblis lagi, berdasarkan logika bahwa pertanyaan media sekarang muncul di dalam pemilih, penjaga secara teoritis dapat mengikuti prinsip yang sama.

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

  background-color: @coreBackgroundColor;

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

or

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

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

Lebih deklaratif daripada ifs, sintaks yang lebih dekat ke KURANG yang ada, dan mengevaluasi setiap pernyataan secara independen (seperti KURANG/CSS didefinisikan).

Atau (atau sebagai tambahan), dengan cara yang sama, melampirkan evaluasi mixin ke titik evaluasi:

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

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

Diperdebatkan, penjaga tingkat pernyataan tidak lebih / kurang kompleks atau logika yang berbeda dari penjaga tingkat campuran IMO. Mungkin contoh 2 dan 3 kurang ekspansif ke bahasa. Hanya berpikir saya akan melemparkannya ke sana untuk pemikiran / diskusi.

Saya kira tidak ada yang bisa berbicara banyak tentang proposal penjaga deklarasi saya. ;-)

Sebenarnya, tidak, tidak banyak yang bisa dikatakan. Itu akan menjadi hal yang hebat, IMO :)

Ya, jika mereka sudah ada di mixin, dan kueri media bisa berada di dalam elemen, sepertinya logika untuk memperluasnya masuk akal. Penasaran apa yang dipikirkan @lukeapage dan @jonschlinkert dan yang lainnya.

@matthewdl :+1:

Pikir saya sudah mendukung mereka pada masalah yang mereka diskusikan .... :)

@lukeapage Apakah Anda berbicara tentang masalah #748? Jika demikian, saya telah menambahkan sedikit ke sintaks. ;-)

Saya ingin berpadu dalam mengekspresikan keinginan saya untuk beberapa bentuk if atau @when .

Saya tidak setuju dengan sentimen bahwa penjaga secara universal lebih baik dan membuat kode KURANG kurang kompleks daripada menggunakan persyaratan. Saya menemukan situasi praktis di mana penjaga sebenarnya membuat file KURANG saya lebih buruk dan lebih sulit untuk dibaca tetapi if / @when sebenarnya akan sangat mudah dibaca. Penjaga dan if / @when pada dasarnya hanyalah alat, keduanya dapat digunakan untuk membuat sesuatu menjadi indah atau jelek dan lebih cocok untuk situasi yang berbeda. Neraka, saya dapat membuat file .less ~300b yang hanya menggunakan fitur ekspansi selektor paling dasar KURANG untuk menghabiskan lebih dari 1GB RAM dan membiarkan CPU berputar selama beberapa menit.

Dalam proyek baru-baru ini yang sedang saya kerjakan dengan maksud untuk mendukung desktop dan seluler, saya akhirnya memutuskan bahwa melakukan ini dengan kueri media sebaris tidak cukup baik. Melayani css ekstra ke salah satu mode yang bahkan tidak akan digunakan tidak terdengar bagus, ditambah seluruh masalah dengan mencoba mengalirkan gambar latar belakang memuat dua kali dan harus mengatasinya sementara masih tidak dapat menyematkan URI data tanpa membuang waktu menyajikan seluruh gambar yang tidak akan digunakan oleh mode. Dan menangani ini dengan mencoba mengalirkan dua lembar gaya hanya akan membuat kekacauan yang lebih kecil karena sekarang akan ada dua tempat yang mendeklarasikan gaya untuk satu kelas.

Keputusan saya adalah mengambil satu halaman dari cara MediaWiki menangani RTL, dengan menyajikan dua lembar gaya dari satu. MediaWiki melakukan ini dengan menulis stylesheet di LTR dan kemudian membalik stylesheet untuk membuat stylesheet RTL kedua. Tidak perlu mencoba dan menimpa semua yang ditentukan untuk LTR untuk menangani RTL. Demikian juga saya memutuskan saya akan menulis gaya utama saya di main.less (dan berpotensi file yang dirujuk darinya untuk memisahkan gaya), file itu tidak akan dikompilasi secara langsung. Sebagai gantinya saya akan memiliki dua lembar gaya desktop.less dan mobile.less, keduanya akan mengatur hal-hal seperti <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; , dan juga menimpa beberapa variabel yang lebih sedikit seperti ukuran benda. Dengan cara ini main.less saya akhirnya berubah menjadi desktop.css dan mobile.css, dan saya dapat menangani kueri/pengujian media menentukan mana yang akan dimuat di tempat lain (jika saya BENAR-BENAR ingin, saya benar-benar dapat menentukan mana yang akan dimuat bahkan pada perangkat yang bahkan tidak mendukung kueri media).

Namun satu masalah adalah blok bersyarat. Ada bagian dari kode yang saya putuskan "seluler tidak memerlukan gaya ini" atau "desktop tidak memerlukan gaya ini". Saat ini satu-satunya cara saya dapat melakukan ini dalam waktu lebih sedikit adalah dengan:
((Ok, secara teknis gaya ini bersifat hipotetis karena saya tidak menggunakan navigasi akordeon tetapi tetap sesuai dengan apa yang saya lakukan))

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

Dalam situasi ini akan jauh lebih dimengerti untuk menggunakan sesuatu seperti @when .

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

Saya sebenarnya mempertimbangkan untuk memproses lebih dulu file saya yang lebih sedikit untuk mengubah sesuatu seperti sintaks @when menjadi peretasan di mana mixin+guard yang dihasilkan secara dinamis dibuat dan kemudian dimasukkan langsung setelahnya.
Tak perlu dikatakan, jika ide pra-pemrosesan pra-prosesor terdengar seperti ide bagus yang akan membuat segalanya lebih mudah dipahami... ada yang salah dengan pra-prosesor saat ini.

Dan sebenarnya ini tidak hanya berlaku untuk teknik desktop/seluler saya. Ini bisa sama-sama berlaku untuk skema tema. Tulis satu file utama dengan tema Anda. Kemudian memiliki banyak file yang lebih sedikit Anda cukup memasukkan file yang lebih sedikit ke dalam dan kemudian mengatur beberapa variabel yang lebih sedikit untuk mengontrol hal-hal seperti skema warna. Tweak warna akan bekerja dengan baik, tetapi Anda akan segera kabur begitu Anda menemukan bahwa Anda benar-benar dapat menggunakan sesuatu seperti @use_horizontal_nav .

@dantman pada 1.5.0 dan menjaga gaya css yang ditautkan, Anda dapat melakukan ini

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

yang merupakan gula untuk contoh Anda.

Satu-satunya downside adalah bahwa saat ini ia berpikir bahwa itu adalah pemilih baru sehingga tidak menggabungkannya dengan pemilih sebelumnya. Namun saya pikir ini tidak mungkin menyebabkan masalah bagi Anda dan akan menjadi sesuatu yang saya/Kami akan perbaiki di versi mendatang.

Oke terima kasih, bisakah kami mendokumentasikannya sebagai fitur?

Sejujurnya saya juga tidak yakin itu sangat bisa dimengerti dibandingkan dengan @when , saya tidak yakin jika sebelumnya saya pernah melihat & when(...) dalam file .less saya akan mengerti apa itu melakukan sekilas. @when sebagai gula untuk & when() bisa menyenangkan.

Saya setuju dengan @matthew-dean menambahkan struktur bersyarat semacam ini kemungkinan akan membuat file inti KURANG lebih sulit untuk dipelihara dan diuji. Dan file .less lebih sulit untuk di-debug dan sebagainya.

Apa yang kami dapatkan sekarang adalah sebuah karya seni, orang dapat memahami dan mempelajari dasar-dasar KURANG dalam waktu kurang dari 10 menit (saya berbicara tentang bersarang dan mencampur), menambahkan pernyataan bersyarat hanya membuat segalanya lebih sulit untuk dicerna oleh jenis orang lain seperti desainer dan penggemar. mencoba menggunakan penjaga untuk meniru atau mensimulasikan pernyataan JIKA hanya mencoba memperburuk masalah yang tidak ada dan tidak membutuhkan solusi.

Jika pengembang membutuhkan lebih banyak kerumitan dan kontrol atas file KURANG mereka sebelum mengompilasinya, tidak ada yang menghentikan mereka untuk menggunakan bahasa seperti PHP untuk memproses lebih dulu beberapa file yang lebih sedikit untuk mencapai kontrol, fleksibilitas, dan kompleksitas yang lebih besar, ada banyak cara untuk melakukan ini hanya masalah menggunakan imajinasi untuk melakukan ini dengan cara yang paling benar atau nyaman.

Misalnya jangan katakan saya memiliki file bernama "myfile.less.php" yang memiliki kode gila dengan kondisional, sakelar, array, dan semua hal mewah yang dapat Anda lihat di PHP dan kemudian dari file ".less.php" itu meludah file lain disebut "myfile.less" yang memiliki kode KURANG akhir, dengan cara ini saya dapat menanyakan semua server vars dengan PHP, memutuskan apa yang @imports file .less baru saya akan menyertakan atau mengecualikan, tidak perlu lagi meneruskan sejumlah besar var konyol ke compiler KURANG dan tidak perlu menulis jelek, sulit dibaca penjaga konyol untuk meniru dari mensimulasikan JIKA atau Beralih struktur.

Alur kerja dasar bisa seperti ini

1- periksa apakah cache kedaluwarsa
1- skrip panggilan untuk menemukan dan memproses semua file ".less.php" file
2- panggil skrip untuk mengkompilasi semua file ".less"
3- perbarui cache

@enav Saya sangat tidak setuju. serta mengembangkan lebih sedikit saya menggunakannya dalam solusi perusahaan berdasarkan simpul teratas, di mana kami tidak ingin harus menggunakan 2 bahasa untuk menyelesaikan masalah.

@dantman ada beberapa hal yang tidak didokumentasikan dan ya, kita perlu mendokumentasikannya. ada upaya yang dilakukan di less-docs untuk memperluas dokumentasi dan membuat situs web jauh lebih baik. Saya akan menambahkan masalah di sana.

@lukeapage , ya saya perhatikan baru-baru ini. Saya membaca sekilas changelog dan memperhatikan hal-hal seperti svg-gradient dan properti yang bergabung dengan +.

Sebenarnya & when ... sudah didokumentasikan karena ini hanya kombinasi sederhana dari dua fitur yang didokumentasikan & dan CSS Guards . Tapi contoh yang berdedikasi tidak akan merugikan tentu saja.

@seven-phases-max, saya tidak mengetahui dokumentasi itu. Dari kelihatannya, itu adalah kumpulan dokumentasi baru yang tidak lengkap untuk menggantikan situs lama, dengan "Ini akan segera dipindahkan ke repo lesscss.org! Kami menyarankan Anda untuk menghindari menautkan ke situs ini sampai semuanya ditayangkan." komentar. Yang bagus untuk mengetahui bahwa sesuatu seperti itu sedang dikerjakan.

Saya mengacu pada dokumentasi saat ini di lesscss.org yang merupakan satu-satunya dokumen yang saya ketahui, dan saat ini hanya mendokumentasikan penjaga sebagai fitur mixin, tidak menunjukkan bahwa itu tersedia di tempat lain.

Penjaga tidak sebaik ini. :(

Ini adalah fitur yang diperlukan dan juga ada di scass.

+1 untuk ini

Sejak komentar hari ini diangkat beberapa tahun setelah terbitan ini dibuka, satu hal yang akan saya tunjukkan yang terlintas dalam pikiran saat ini.

Beberapa penolakan terhadap @when dalam diskusi awal adalah aturan tambahan. Namun, memikirkannya sekarang, itu seharusnya tidak diperlukan.

Mempertimbangkan bahwa kedua blok ini sama:

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

Maka kedua pernyataan ini juga harus diterima oleh parser sebagai sama.

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

Jika tidak ada alasan lain selain & when secara sintaksis sangat canggung. Menghilangkan & untuk tetap menyiratkan gabungan pemilih dengan pemilih induk telah ada selama ini, jadi menghilangkan & untuk menyiratkan penjaga pada pemilih induk sepertinya bukan lompatan. Selain itu, fungsi block-root sekarang diterima oleh parser untuk digunakan dengan plugin, sehingga tidak lagi terlihat aneh seperti pada tahun 2013.

Saya tidak melihat alasan untuk membuka kembali ini. Lagi pula kita sudah memiliki #2072

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

Membuka kotak kebingungan yang hebat hanya demi ekonomi dua karakter?

Penjaga tidak sebaik ini.

Saya pikir tidak ada gunanya mengomentari komentar acak yang tidak masuk akal. Posisi apa pun harus memiliki sesuatu di belakangnya (Kalau tidak, saya akan mengatakan kode bersyarat apa pun lumpuh dan if s konyol hanya karena saya tahu cara menulis _anything_ bahkan tanpa satu kondisi pun di hampir setiap bahasa).

Saya tidak melihat alasan untuk membuka kembali ini. Lagi pula kita sudah memiliki when (1=1) { color: blue; }

Errr ... tidak kita tidak?

Tapi itu wajar bahwa kita harus. Kami hanya bisa membiarkannya dan menyelesaikannya.

Tunggu, sampai saya menemukan permintaan fitur yang seharusnya ditautkan (maaf, saya tidak sengaja mengklik enter sebelum menyelesaikannya)

Jadi gabungkan ini ke #2072.

@seven-fase-max

Masalah itu disebut "Izinkan redefinisi variabel di dalam blok berjalan mandiri yang dijaga" dan diskusi tangensial di bagian bawah masalah itu berisi kasus penggunaan analog dengan pilih / kasus dan vbscript iif([ifcond], [then], [else]) berfungsi lebih dari sekadar saat telanjang, meskipun mungkin ini merupakan pikap yang lebih logis untuk diskusi. Buuut... mungkin itu harus diangkat sebagai masalah baru hanya dengan pertanyaan when () vs & when () .

hanya dengan pertanyaan when () vs & when ().

Anda tidak bisa serius dalam hal ini, bukan? Karena apa sebenarnya? when tidak akan menjadi if (lihat #2072 untuk semua alasan) jika Anda menghapus & . Jadi biarkan apa adanya dan selesaikan.

Hei, bisakah kamu mengurangi nadanya? Jika Anda kesal, luangkan waktu sejenak dan kembali lagi nanti untuk melihat alasan yang saya posting di edisi baru. Beberapa hal telah berkembang sejak diskusi awal ini.

Saya tidak bermaksud menyinggung atau apa.
Ku:

Jadi biarkan apa adanya dan selesaikan.

itu hanya balasan untuk:

Kami hanya bisa membiarkannya dan menyelesaikannya.

@seven-phases-max Oke, nada hilang dalam teks. Bagaimanapun, saya tidak terlalu terikat dengan ide ini, dan secara keseluruhan, proposal @when yang ada lebih baik / lebih fleksibel.

Saya pikir 'sass' lebih baik daripada kurang. Itu sudah memiliki if-else. Ini sangat sulit dan banyak baris pengkodean semakin sedikit. Ketika bekerja tetapi tidak memenuhi kebutuhan. Selain itu, kita dapat membuat loop dalam waktu yang lebih sedikit tetapi bahasa harus memiliki fiturnya sendiri.

@aukgit Gunakan alat yang tepat untuk pekerjaan itu. Jika SCSS lebih cocok untuk Anda, lebih baik menggunakannya. Sass dan Less adalah proyek yang sangat berbeda.

@matthew-dean setelah belajar lebih sedikit selama berbulan-bulan dan menulis lebih sedikit jika komunitas 'kurang' tidak ingin menjadi lebih baik maka kerugian bagi kami berdua. Saya pikir itu sebabnya bootstrap pindah ke 'sass' (https://github.com/twbs/bootstrap/tree/v4-dev) dari less (alasan awal kompilasi lebih cepat). Padahal sumber awalnya ada di 'kurang'. Sekarang mereka menulis sumber aslinya dalam 'sass' dan kemudian mengubahnya menjadi less (sedangkan sebaliknya).

Hal lain :

"Alat yang tepat untuk pekerjaan yang tepat"

seharusnya tidak berlaku di sini

Lebih sedikit | sss | Stylus proyek serupa. Berawal dari salah satu yang sedang populer saat itu, kini sepertinya komunitas 'kurang' itu tidak mau berbenah diri.

Ide di balik 'kurang' adalah untuk menulis lebih sedikit dan berbuat lebih banyak. Di suatu tempat itu melakukan pengurangan tetapi di suatu tempat itu membutuhkan lebih banyak tulisan.

Terima kasih atas komentar Anda.

Propaganda fanboyish usang. Akan membuang-buang waktu untuk memperdebatkan semua pernyataan yang bias atau hanya salah ini.

Misalnya:

Tidak ada cara untuk membuat kode kondisional yang benar-benar dikompilasi.

Ya, "Saya memerlukan alat untuk menulis kode spageti saya" - seperti ini . Jika Anda menulis kode seperti ini, memang Less jelas bukan alat Anda.

Saya pikir "kurang" melakukan 'x' sesuatu yang sangat berbeda dari sass dan stylus. Semua yang lain melakukan hal serupa sedangkan 'kurang' mengklaim itu bukan jenis yang serupa. :)

@aukgit

Saya pikir "kurang" melakukan 'x' sesuatu yang sangat berbeda dari sass dan stylus.

_Mengapa_ harus melakukan hal yang sama? Lihat misalnya [1] dan [2] untuk menemukan perbedaan utama antara desain. Jadi Anda mungkin tidak menyukai konsepnya tetapi tidak ada yang memaksa Anda untuk menggunakan alat yang tidak Anda sukai.

Sekarang saya mengerti. Terima kasih. Sungguh, itu benar-benar bahasa yang paling disalahpahami. Bahkan javascript tidak disalahpahami seperti yang dikatakan Douglas Crockford.

Orang-orang membuat kesalahan di js tetapi ada banyak kesadaran. Untuk 'Kurang' itu harus di halaman pertama ( less.org ) menjelaskan apa yang kurang dan apa yang tidak.

Terima kasih.

Menulis campuran:

Lebih sedikit:

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

    .x(@value);
}

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

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

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

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

Keluaran CSS:

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

jika komunitas 'kurang' tidak ingin menjadi lebih baik maka rugi kita berdua

Saya pikir itu adalah kesalahan untuk menganggap bahwa "fitur X yang saya inginkan tidak didukung" == "Komunitas yang lebih sedikit tidak ingin menjadi lebih baik". Itu tidak membawa kita kemana-mana.

Ada beberapa diskusi di Github untuk memperbaiki aliran kontrol. Sebenarnya, utas ini tidak ditolak, tetapi telah digabungkan ke #2072. Anda mengomentari utas berusia 3 tahun yang ditutup. Saya punya beberapa ide lain yang saya pikir mungkin membuatnya sedikit berbeda dari #2072, tetapi pada dasarnya yakin sebaliknya.

sekarang sepertinya suka tidak memiliki fitur yang lebih baik

Less tidak memiliki fitur _more_, ini benar. Ini adalah dengan desain. Ini agar Anda dapat mempelajari Less dalam sehari, dan fitur Less mencakup 99% kasus penggunaan biasa. Sass memiliki kurva belajar yang lebih curam. Sass memiliki begitu banyak fitur yang mengasapi sehingga mereka harus membangun kompiler berbasis C tingkat rendah hanya untuk dapat terus mengompilasinya. Yang merupakan prestasi besar. Tapi bukan bukti yang bagus untuk sesuatu yang, pada akhirnya, hanya membuat style sheet.

Sekarang mereka menulis sumber aslinya dalam 'sass' dan kemudian mengubahnya menjadi less (sedangkan sebaliknya).

Benar, tetapi itu didasarkan pada banyak faktor, dan Anda dapat bertanya kepada mereka apa itu. Saya pribadi merasa bahwa mengabaikan pengguna Less adalah sebuah kesalahan, karena ada banyak orang yang menggunakan Bootstrap di Less hari ini.

Pada akhirnya, keluhan Anda tentang rintangan yang diperlukan untuk menulis persyaratan adalah _tidak salah_. Contoh yang ditawarkan di sini sangat tidak cocok untuk bahasa tersebut. Saya sarankan Anda membaca utas di # 2072.

(ini sebenarnya agak di luar topik, tapi saya hanya ingin tahu)

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

Dan apa gunanya variabel-variabel ini selain memanggil .if-value-present-multi ?
(Dan _if_ variabel-variabel ini _are_ digunakan untuk sesuatu yang lain) Bukankah masuk akal, untuk menggunakan pasangan properti/nilai saja, misalnya:

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

Terlebih lagi, apa gunanya menulis .x {.if-value-present(content, 'new val')} jika Anda hanya perlu .x {content: 'new val'} ? Dan menulis .x {.if-value-present(content)} jika tidak melakukan apa-apa?

(Meskipun kejujuran saya memang melihat [1] - yah, tidak mengomentari apa pun kecuali hanya satu hal: (_hanya untuk menghemat waktu Anda_) pertimbangkan untuk membuang lib kuno seperti elements dan lesshat - dan gunakan autoprefixer sebagai gantinya. Kami tidak memerlukan pustaka awalan vendor untuk praprosesor CSS untuk sementara waktu sekarang).

Ini biasanya bagaimana sebagian besar "permintaan fitur" masuk: "Masalah XY" . (Contoh bagus lainnya dari kegagalan serupa di area terkait: #1400 dan #1894, bukan karena fitur tersebut sama sekali tidak berguna (karenanya keduanya tetap terbuka), tetapi ketika seseorang mulai menanyakan kasus penggunaan mereka yang sebenarnya, biasanya akan terungkap itu hanya salah Y dalam upaya untuk memecahkan X).

Nah berikut use casenya :
Saya mencoba membuat mixn dengan 3 parameter jika yang terakhir tidak diberikan maka itu harus membuat atributnya di dalam mixn itu sebabnya kondisinya berguna.

Di sini https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less Saya telah mencoba menerapkan mixen yang sama berulang kali di mana saya bisa mencapainya dengan syarat sangat mudah.

Saya mengerti sekarang.. Terima kasih semuanya.

@aukgit Anda harus dapat menciutkan mixin itu dengan mudah.

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

Terima kasih @matthew-dean telah meluangkan waktu Anda dan membantu saya. :) Saya besar penuh untuk Anda.

:)

Saya pikir 'sass' lebih baik daripada kurang. Itu sudah memiliki if-else.

Kedua bahasa memiliki masalah mereka sendiri.

Kurangnya impor dinamis mereka - dan keengganan mereka untuk mengimplementasikannya - adalah alasan utama saya ingin beralih dari Sass ke Less. Kurang memiliki fitur ini selama bertahun-tahun!

Namun, kurangnya struktur kontrol tradisional (seperti pernyataan FOR-loop atau IF-ELSE) dan sintaksis yang ngeri adalah yang mencegah saya melakukan langkah ini.

Aku merasa terjebak di antara batu dan tempat yang keras...

@jslegers Komentar yang sama seperti di #249. Less memiliki berbagai bentuk (semakin banyak dalam versi yang lebih baru) dari striktur bersyarat sejak v1.x.

@seven-fase-max

Saya mengetahui mixin yang dijaga sebagai alternatif untuk pernyataan IF dan pencampuran rekursif sebagai alternatif untuk loop di Less. Tapi hanya itu yang bisa saya temukan di dokumen tentang struktur kontrol di Less. Dan sebagai seseorang dengan pengalaman pemrograman dalam banyak bahasa, saya menemukan sintaks mereka membingungkan dan - sejujurnya - cukup ngeri.

Jika ada struktur kontrol lain selain yang layak disebutkan, saya belum dapat menemukannya di dokumen.

Bagaimanapun, sesuatu seperti ...

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

... atau sesuatu seperti ...

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

... atau ini...

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

... di Sass jauh lebih mudah dibaca dan jauh lebih elegan menurut saya daripada harus menulis sesuatu yang mirip dengan mixin yang dijaga atau mixin rekursif di Less.

Kurangnya pernyataan seperti itu dan sintaksis Less secara keseluruhan yang kurang dapat dibaca (dibandingkan dengan Sass) adalah dua alasan utama saya lebih memilih untuk tetap menggunakan Sass dan saya bahkan enggan mempertimbangkan Less untuk salah satu proyek saya.

Dan mengingat Sass telah menjadi jauh lebih populer daripada Less, saya jelas bukan satu-satunya yang merasa seperti itu.

@jslegers Untuk contoh Anda - coba pelajari apa yang sudah tersedia sebelum mempostingnya.
Selebihnya (popularitas dan sebagainya) - tidak ada gunanya membahas sesuatu dengan cara yang terlalu disederhanakan (Stylus memiliki semua ini dan apa?), selain itu Less tidak pernah dinyatakan untuk menggantikan praprosesor CSS lain atau menjadi tiruan mereka. Dan akhirnya, kesalahan paling umum adalah menganggap popularitas sesuatu adalah tujuan utama dan satu-satunya dari penulis sesuatu itu.

coba pelajari apa yang sudah tersedia sebelum mempostingnya.

Cobalah untuk mendokumentasikan dengan lebih baik atau mengarahkan orang secara langsung ke apa yang mereka cari, jika mereka tidak menemukannya.

Selebihnya (populeritas dan sebagainya) - tidak ada gunanya membahas sesuatu dengan cara yang terlalu disederhanakan [...] Dan akhirnya, kesalahan paling umum adalah menganggap popularitas sesuatu adalah tujuan utama dan satu-satunya dari penulis sesuatu itu.

FYI, saya tidak pernah menyiratkan bahwa popularitas adalah indikator kuat untuk kualitas atau kegunaan. Bahkan, cukup sering sebaliknya.

Namun, jika Anda melihat mengapa orang pindah dari Less ke Sass, itu cukup mudah ...

Secara pribadi di sana saya tidak dapat melihat apa pun selain yang biasa "Saya ingin spageti PHP saya" (lihat posting tentang alat yang salah di atas), bahkan tidak termasuk 2012-nya (saya sudah mengisyaratkan bahwa sebagian besar contoh ini berjalan cukup kompak di Less modern, tetapi itu sepertinya Anda tidak ingin bangun).
Tapi tidak apa-apa, biasanya saya hanya memperdebatkan informasi yang salah, diskusi pendapat pribadi tentang mengapa sesuatu terjadi atau tidak benar-benar di luar minat saya.

Secara pribadi di sana saya tidak dapat melihat apa pun selain "Saya ingin spaghetti PHP saya" yang biasa

Tampaknya bagi saya bahwa menggunakan Less daripada Sass membuat kode Anda pasti terlihat seperti "PHP spaghetti" (jika Anda berpikir PHP adalah lambang kode spaghetti, Anda jelas tidak pernah melakukan pemrograman ABAP) segera setelah Anda ingin melakukan sesuatu yang lebih kompleks daripada variabel dasar dan mixin, tetapi saya bersedia mempertimbangkan bahwa saya salah di sini.

Saya sudah mengisyaratkan bahwa sebagian besar contoh ini berjalan cukup kompak di Less modern, tetapi tampaknya Anda tidak ingin bangun

Lalu mengapa tidak berusaha membangunkan saya dan memberi saya satu atau dua sumber yang bisa membebaskan saya dari ketidaktahuan saya?

Ada sedikit yang menurut saya lebih menarik daripada seseorang yang membuktikan bahwa saya salah. Menurut pengalaman saya, itulah cara terbaik untuk tumbuh...