Less.js: :perpanjang mixin

Saya menyukainya, tetapi untuk memperjelas.. ini tidak memungkinkan Anda melakukan sesuatu yang tidak dapat Anda lakukan sebelumnya, itu hanya berarti Anda mendapatkan..

.navbar,
.banner {
    // clearfix stuff
}

daripada

.navbar {
    // clearfix stuff
}
.banner {
    // clearfix stuff
}

atau saya salah paham?

Saya ingin memiliki keduanya, mixin parametrik dan biasa, untuk dimiliki

.navbar,
.banner {
    // clearfix stuff
}
.....

atau

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}
....

kapan pun Anda membutuhkan, saya tahu ini adalah cara simular bagaimana mixin sudah bekerja, jadi pertanyaannya sebagian besar memiliki fleksibilitas dan cara untuk menangani keluaran CSS akhir dengan lebih baik dalam hal pengoptimalan.

pasti

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}

lebih pendek dari

 .clearfix {
    // clearfix stuff
  }
 .navbar{
    // clearfix stuff
 }
.banner {
    // clearfix stuff
}

dan untuk contoh yang lebih rumit yang bisa menjadi kritis, dan saya tahu beberapa orang beralih ke SASS hanya karena kekurangan ini

Mixin biasa tidak bisa berubah. Mereka cukup banyak perlengkapan Kurang. @agatronic , ya saya juga melihatnya seperti itu. Ada tantangan untuk ini, seperti apakah kita dapat memperluas mixin parametrik? Dan jika demikian bagaimana cara kerjanya? Dengan asumsi ini didukung, katakanlah Anda memperluas mixin parametrik dua kali tetapi menggunakan variabel yang berbeda setiap kali, seperti ini:

.transition(@transition) {
  -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}
.navbar {
    &:extend(.transition(opacity .2s linear));
}
.banner {
    &:extend(.transition(opacity .3s linear));
}

Saya membayangkan itu mungkin membuat dua salinan mixin, yang merupakan kode yang tidak kalah, dan tidak ada keuntungan dari mixin biasa:

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

Namun, Anda mungkin sering menggunakan mixin khusus ini, jadi ketika Anda menggunakan mixin lagi pada .dropdown dengan variabel yang sama dengan .banner , mungkin hasilnya seperti ini:

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner,
.dropdown {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

Dan inilah yang membuat ini menarik bagi saya. akan lebih baik untuk mendengar umpan balik dari orang lain juga

@jonschlinkert ya, itu ilustrasi yang lebih baik, terima kasih. seperti yang saya katakan kedua tangan itu! tetapi pahami meskipun itu menambah tingkat keterlibatan lain, dan perlu dilakukan/tidak dilakukan dengan serius

Ekstensi dalam metode yang Anda referensikan dapat dicapai dengan cukup mudah dengan pola ini:

.transition(@transition) {
    -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}

.quickOpacity1(){
    .transition(opacity .2s linear);
}

.quickOpacity2(){
    .transition(opacity .3s linear);
}

.navbar{
    .quickOpacity1();
}

.banner,
.dropdown{
    .quickOpacity2();
}

Di atas menyuntikkan mixin semi-diperpanjang ke dalam 2 deklarasi baru.

Untuk clearfix juga mudah untuk menggunakan pola serupa di bawah ini, yang tidak hanya akan membuat clearfix sebagai kelas, tetapi menyuntikkan gaya clearfix tersebut ke dalam deklarasi baru.

.clearfix{
  //clearfix stuff
}
.navbar,
.banner {
    .clearfix;
}

@krismaister Saya pikir mungkin ada kebingungan tentang ini. Pola yang Anda gambarkan sebenarnya hanyalah mixin bersarang, atau pola pewarisan mixin. Memperluas pekerjaan dalam kebalikan dari itu.

@jonschlinkert Mixin warisan - nama yang bagus. Tampaknya kedua contoh di atas mencoba mewarisi output dari induknya - yang merupakan fitur inti dari ekstensi. Anda mungkin setuju bahwa output dari contoh saya adalah output yang Anda harapkan.

Saya mengerti dari membaca ulang komentar asli Anda - Anda ingin output digabungkan menjadi satu aturan CSS. Meskipun itu ditulis sebagai 2 awalnya.

Sebenarnya :extend cukup mengagumkan. Saya akan menjadi kutu buku penuh, tetapi semuanya bermuara pada "apa yang dipindahkan ke mana". Pikirkan mixin seperti "menyebarkan properti mixin ke pemilih yang menggunakannya". Dan pikirkan :extend sebagai kebalikannya, "menyebarkan selektor yang menggunakannya ke mixin itu sendiri." Bukan properti _selector, hanya pemilih itu sendiri. Jadi jika Anda melakukan ini:

.some-mixin() {
    padding-top: 100px;
    background: #f7f7f7;
}


// a selector that is extending the mixin
.alert:extend( .some-mixin() ) {
    border: 1px solid #e5e5e5;
}
// another selector extending the mixin
section:extend(.some-mixin()) {
    margin: 20px 0;
}

Ini akan menghasilkan ini:

// The selectors that extended the mixin are now where the mixin used to be.
.alert,
section {
    padding-top: 100px;
    background: #f7f7f7;
}

// And the properties of the mixin did not get copied down below
// so we saved a line or two of code.
.alert {
    border: 1px solid #e5e5e5;
}
section {
    margin: 20px 0;
}

Semoga itu lebih masuk akal. Saya senang membantu kapan saja.

@agatronic , @matthewdl , @DesignByOnyx , hanya sebuah pemikiran, saya tahu ini adalah pendekatan yang tidak biasa, tetapi dengan asumsi tidak ada tantangan teknis untuk ini, dan dengan asumsi kami mengizinkan daftar pemilih yang dipisahkan koma, mungkin memperpanjang _should_ merasa lebih seperti array . Apa pendapat Anda tentang mengubah sintaks menjadi: :extend[N] .

Saya pikir lebih mudah di mata juga ketika mixin diperpanjang:

section:extend[.some-mixin(), .another-mixin()] {
    margin: 20px 0;
}

Saya baik-baik saja, tetapi ada sesuatu yang terasa benar tentang tanda kurung siku.

@jonschlinkert - [] berarti atribut dalam css, bukan array, di mana :extend() dipilih karena tautannya ke penyeleksi semu, jadi saya pikir tanda kurung normal harus tetap ada.

poin yang bagus, saya setuju.

Saya setuju bahwa tanda kurung terlihat dan terbaca bagus, tapi ya kita harus tetap menggunakan sintaks yang telah kita pilih.

jempol untuk sintaks extend(N), lebih terasa seperti alam CSS, alasan yang sama dengan @agatronic

Memperpanjang mixin bukanlah ide yang buruk. Tidak yakin tentang contoh sintaks, @jonschlinkert. Bukannya saya tidak menyukainya; Aku hanya benar-benar tidak mengerti apa yang Anda tulis.

Saya pikir yang Anda maksud adalah Anda ingin mendefinisikan kelas yang "menarik" konten mixin yang sama, tetapi tidak benar-benar mengulang dalam CSS yang dihasilkan. Saya tidak akan menyebutnya mixin yang diperluas. Artinya, Anda tidak mengubah definisi mixin (dengan cara yang sama seperti definisi perluasan pada penyeleksi), Anda sebenarnya mengubah (memperluas) kelas yang dihasilkan.

Jadi, koreksi saya jika saya salah, tetapi apakah contoh navbar / banner / dropdown Anda tidak didukung oleh:

.navbar {
  .transition(opacity .2s linear);
}
.banner {
  .transition(opacity .3s linear);
}
.dropdown:extend(.banner) { }

Artinya, memperluas kelas seperti biasa? Saya hanya mencoba untuk memahami pola penggunaan Anda, dan penggunaan extend untuk mixin tampaknya bertentangan dengan penggunaan dan nomenklaturnya untuk memperluas pemilih. Bisakah Anda memberikan detail lebih lanjut tentang mengapa Anda perlu / ingin mereferensikan mixin dalam panggilan ekstensi, dan tidak memperluas pemilih yang mereferensikan mixin?

Begitulah cara saya mendapatkannya

OUTPUT CSS AKHIR YANG DIINGINKAN

.sometingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.anotherClass,
.anotherYetClass {
    // did something dynamic with a
}

.yetClass {
    // did something dynamic with b
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

CARA YANG HARUS ANDA LAKUKAN DENGAN VERSI LANCAR DARI KURANG UNTUK MENDAPATKAN OUTPUT YANG DIINGINKAN

.somethingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass,
.anotherYetClass {
    .someMixin(a);
}

.yetClass {
    .someMixin(b);
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

SINTAKS KURANG YANG DISARANKAN

.somethingShared {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass:extend(.sometingShared, .someMixin(a)) {
    // native another class code
}

.anotherYetClass:extend(.sometingShared, .someMixin(a)) {
    // native another yet class code
}

.yetClass:extend(.sometingShared, .someMixin(b)) {
    // native yet class code
}

Meskipun ekstensi dapat berguna hanya jika Anda benar-benar memiliki jumlah kode yang dibagikan, dalam kasus lain penggunaan mixin biasa lebih disukai.

Dan hanya sedikit, sampel boneka langsung, yang bertujuan hanya untuk bermain-main

http://jsbin.com/opekon/1/edit
http://jsbin.com/opekon/2/edit
http://jsbin.com/opekon/3/edit
http://jsbin.com/opekon/4/edit

seperti yang dikatakan, mungkin ada peningkatan kinerja dalam keadaan tertentu bagi orang-orang yang malas seperti saya :) untuk mengoptimalkan kode KURANG hanya karena dipengaruhi fleksibilitas lebih lanjut

Berikut adalah posting blog yang bagus tentang ekstensi yang mencakup beberapa hal tentang bagaimana SASS menangani perluasan, dan mungkin bijaksana bagi kita untuk belajar dari bagaimana orang lain melakukan ini. http://designshack.net/articles/css/semantic-grid-class-naming-with-placeholder-selectors-in-sass-3-2/

Secara khusus, saya percaya proposal saya untuk memperluas mixin pada dasarnya akan mencapai hasil akhir yang sama dengan "placeholder" SASS, tetapi tanpa harus membuat kelas khusus placeholder yang tidak berguna dan berlebihan.

EDIT: ya, ini adalah posting lain yang merangkum placeholder dengan baik. Persis seperti yang saya usulkan dengan memperluas mixin http://maximilianhoffmann.com/article/placeholder-selectors

Saya pribadi lebih suka ini di atas semua fitur terkait perluasan lainnya. Tanpa pertanyaan. Ini adalah pernyataan yang kuat, tetapi saya pikir saya tidak menjelaskannya dengan baik jika orang lain tidak setuju. Ini adalah hal yang cukup kuat.

Saya merasa SASS itu

 %tile {
  width: 200px;
  height: 200px;
  margin-right: 20px;
}

sama dengan mixin parametrik, dirancang untuk perluasan secara eksklusif, yang mungkin tidak terlalu buruk dalam hal pemisahan masalah. tapi ya itulah CSS, dan bukankah seharusnya sesederhana mungkin?

@agatronic sementara kita berbicara tentang, apa ini memperpanjang https://github.com/agatronic/less.js/blob/master/lib/less/tree/extend.js seharusnya? mencatat itu sudah di cabang utama yang lebih sedikit. maaf untuk pertanyaan noob sekalipun.

@dmi3y ini adalah versi perpanjangan pertama yang ditarik dari permintaan tarik yang siap untuk 1.4.0 - ini mewakili node perpanjangan

terima kasih @agatronic , sekarang saya melihat betapa saya merindukan;)

@dmi3y jangan ragu untuk terus menambahkan percakapan, mari kita coba untuk menjaga masalah ini di tingkat yang lebih tinggi sehingga kita bisa menarik kesimpulan. Juga jangan ragu untuk mengirim email kepada saya secara pribadi, saya senang mendiskusikan bagaimana mixin dan perluasan bekerja dengan Anda (info kontak saya ada di profil saya). Juga komentar cepat untuk menghindari kebingungan lebih lanjut di utas ini. Contoh Anda:

%tile {
    width: 200px;
    height: 200px;
    margin-right: 20px;
}

Ini adalah sintaks untuk "placeholder" SCSS, yang diimplementasikan dalam spesifikasi SCSS untuk mencapai sesuatu yang mirip dengan apa yang saya usulkan dengan memperluas mixin. Tapi ini tidak ada hubungannya dengan menjadi parametrik. Mixin parametrik hanyalah _mixin yang menerima parameter_, artinya nilainya dapat berubah setiap kali digunakan.

@matthewdl

Saya pikir yang Anda maksud adalah Anda ingin mendefinisikan kelas yang "menarik" konten mixin yang sama, tetapi tidak benar-benar mengulangi dalam CSS yang dihasilkan

dan

tidakkah contoh navbar/banner/dropdown Anda didukung oleh...

Tidak, titik operasinya terlewatkan, justru sebaliknya. Mungkin kebingungan itu disebabkan karena saya membuat kesalahan dengan berfokus pada mixin parametrik dalam contoh saya.

Jadi pertama, saya pikir penting untuk menggambarkan bahwa tidak semua mixin adalah parametrik, banyak yang dibuat untuk _tidak_ menerima parameter. Beberapa mixin, seperti clearfix, digunakan berulang kali tanpa mengubah variabel apa pun saat digunakan. Ini adalah kasus penggunaan yang sempurna mengapa memperpanjang mixin akan menguntungkan.

Parametrik atau tidak, dalam semua mixin kemuliaan mereka memiliki kelemahan karena setiap kali digunakan, propertinya diduplikasi . Jadi izinkan saya mencoba menjelaskan bagaimana cara memperluas mixin hanya dengan menggunakan "mixin biasa", dan melanjutkan dengan contoh yang Anda gunakan di atas.

Mengingat contoh Anda, ada dua poin yang sepenuhnya independen dan tidak terkait yang perlu dibuat:

1. kelas spanduk masih akan muncul di CSS yang dikompilasi apakah diperpanjang atau tidak, tetapi jika kelas spanduk adalah mixin, itu hanya akan muncul di CSS yang dihasilkan jika digunakan (baik diperpanjang atau dicampur). Ini saja yang berharga. Dan
2. Saat Anda _memperluas mixin_, daripada menduplikasi properti persis yang sama berulang-ulang, kami akan menyalin pemilih sebenarnya sendiri ke tempat mixin.

Tapi ini hanya salah satu contoh. Pertimbangkan bahwa pada satu titik di Twitter Bootstrap, mixin .clearfix() saja digunakan lebih dari 20 kali di dalam pemilih lain, DAN itu juga bersarang di dalam 4 atau 5 mixin struktural lainnya, seperti .container-fixed() , .make-row() , dan #grid > .core() . Artinya mixin tersebut _juga_ menduplikasi properti mixin clearfix setiap kali digunakan. Dan ini tidak unik untuk kerangka itu.

Apakah ini lebih masuk akal? Jadi, alih-alih membuat properti dari mixin clearfix diduplikasi lebih dari 20 kali, kami akan mengelompokkan pemilih yang menggunakan mixin clearfix di tempat mixin itu sendiri, dan properti hanya akan dideklarasikan sekali . Dan sekali lagi, ini hanya satu mixin, bayangkan keuntungan bersih dari memperpanjang kehilangan mixin biasa, dibandingkan dengan menduplikasi propertinya. Seperti yang saya sebutkan di suatu tempat di atas, mixin biasa masih perlu digunakan tanpa diperpanjang kadang-kadang, untuk kekhususan dan penggantian, tetapi itu tidak mengurangi nilai memperluas yang tidak. Sebenarnya, saya pribadi akan membuat mixin tambahan untuk digunakan secara khusus dengan perpanjangan, yang tidak akan saya gunakan sebaliknya.

Dan contoh kedua saya di atas berfokus pada bagaimana perluasan akan bekerja dengan mixin parametrik, jadi semoga ini melengkapi gambar dan lebih masuk akal sekarang? Jika tidak, artikel yang saya tautkan di atas akan menjernihkan kebingungan. Memperluas mixin sangat kuat dan berguna dan akan memungkinkan Anda untuk mencapai hasil bersih yang sama seperti memperluas pemilih bersarang, tetapi dengan mixin secara khusus alih-alih pemilih bersarang apa pun. Ini memungkinkan Anda untuk mengatur penyeleksi Anda dengan cara yang paling mungkin untuk memberikan hasil yang Anda inginkan, dan menghindari konsekuensi yang tidak diinginkan. @DesignByOnyx , @agatronic , @matthewdl , apakah ada yang saya lewatkan atau lupakan di sini? Adakah yang bisa kita lakukan untuk menghilangkan kebingungan?

Terima kasih. Saya pikir saya mengerti kasus penggunaan, dan saya pikir baris ini mengatakan yang terbaik:

kelas spanduk adalah campuran yang hanya akan muncul di CSS yang dihasilkan jika digunakan (baik diperpanjang atau dicampur)

Itu masuk akal bagi saya. Mungkin yang membuat saya terpaku adalah bahwa keseluruhan sintaks :extend belum final. Tapi, Anda membuat kasus persuasif.

Saya akan mengatakan bahwa setelah kami menyelesaikan blok pemilih, jika perilaku memperluas mixin akhirnya cocok dengan perilaku memperluas pemilih (dengan perbedaan utama adalah baris yang baru saja Anda katakan, bahwa tidak ada pemilih yang dihasilkan dalam CSS untuk perpanjangan KECUALI ada penggunaan awal), maka itu intuitif bagi saya.

Yaitu, jika saya juga bisa melakukan sesuatu seperti ini (atau sintaks yang setara):

.facebook-button:extend( .button() all ) {
    border: 1px solid #e5e5e5;
}

... lalu acungan jempol dari saya. Tapi, bagi saya, semua itu tergantung pada apa/bagaimana/jika kita menyelesaikan :extend untuk penyeleksi. Tapi, selain sintaks, sebagai ide fitur, Anda benar, itu bagus.

@jonschlinkert terima kasih, sangat menghargai dukungan Anda, dan pasti akan mencoba yang terbaik dengan menempatkan pikiran saya sejelas mungkin. Saya pikir cukup menarik untuk mendengar apa yang terjadi dengan perkembangan masa depan dan ya, untuk didengar. Kalian semua, lakukan pekerjaan yang luar biasa dengan itu.

Ya, contoh ini, saya harus eksplisit dengan posting saya sebelumnya.

%tile {
   width: 200px;
   height: 200px;
   margin-right: 20px;
 }

diambil dari tutorial SASS yang disediakan oleh Jon, dan tujuan utamanya untuk menghindari membuang keluaran dalam CSS dari kelas yang tidak akan digunakan. Jadi di sudut tertentu ini bisa dilihat seperti mixin parametrik kosong di KURANG. Ketika Anda ingin menggunakannya tetapi tidak ingin itu dikeluarkan ke stylesheet akhir.

Saya melompat ke dalam diskusi ini dan ingin memberikan kejelasan untuk diri saya sendiri pada komentar berikut:

jika kelas spanduk adalah campuran, itu hanya akan muncul di CSS yang dihasilkan jika digunakan (baik diperpanjang atau dicampur)

Jadi, dengan contoh clearfix yang lebih umum, apakah ini CSS yang KURANG dan dihasilkan?:

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }

    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.clearfix:before,
.clearfix:after,
.something:before,
.something:after {
    content: " ";
    display: table;
}
.clearfix:after,
.something:after {
    clear: both;
}
*/

Saya awalnya mengharapkan kelas .clearfix tetap dihilangkan dari CSS yang dikompilasi. Secara pribadi, saya tidak akan _membutuhkan_ kelas dalam CSS yang dikompilasi, karena saya tidak akan menggunakannya dalam markup dan itu adalah byte tambahan di CSS saya. Saya tidak benar-benar memiliki pendapat yang kuat, tetapi klarifikasi tentang hal ini akan membantu saya membuat komentar yang lebih baik untuk kedepannya. Terima kasih.

apakah ini ... CSS yang dihasilkan?:

Saya senang Anda bertanya, tetapi tidak , hanya kelas .something akan muncul di CSS yang dihasilkan. Jadi Anda benar dalam harapan awal Anda.

cukup baca tautan placeholder dan ya saya pikir memperluas mixin adalah cara yang lebih baik dan lebih sedikit untuk melakukan sesuatu dan mendapatkan fungsionalitas yang sama.

Untuk mengkalibrasi titik Anda di atas

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }
    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.something:before,
.something:after {
    content: " ";
    display: table;
}
.something:after {
    clear: both;
}
*/

dan mungkin jika definisi .clearfix() { adalah .clearfix { maka memanggilnya dengan atau tanpa tanda kurung di dalam definisi perluasan tidak akan membuat perbedaan pada output..

Menggunakan sintaks kelas semu untuk fitur perluasan benar-benar SALAH,
karena "extend sth" TIDAK sama dengan "match sth", itu tidak berarti apa-apa tentang struktur DOM yang seharusnya dipilih oleh pemilih.

Kalian KURANG telah "menemukan" banyak ide buruk. Yang paling terkenal adalah "reuse' .xxx (pemilih kelas) sebagai notasi mixin. Setidaknya ini memudahkan migrasi dari CSS biasa ke preprosesor. Tapi sintaks :extend adalah ide terburuk yang pernah saya dengar.

Saya tidak ingin memuliakan kata-kata kasar semacam ini tentang Masalah kami, tetapi ini bukan pertama kalinya saya mendengar hal-hal ini jadi mari kita bicara tentang CSS dan membersihkan udara.

Kalian KURANG telah "menemukan" banyak ide buruk. Yang paling terkenal adalah "reuse' .xxx (pemilih kelas) sebagai notasi mixin. .... :extend sintaks adalah ide terburuk yang pernah saya dengar.

.xxx disebut campuran implisit. Ini bekerja, dan mudah dimengerti. Faktanya, sintaks ini tidak "invasif" pada spesifikasi CSS seperti, katakanlah, menggunakan at-rules untuk penataan aktual. @keyframes datang paling dekat dengan apa yang akan digambarkan sebagai gaya dan dapat _mungkin_ dianggap pengecualian untuk apa yang saya katakan karena pengidentifikasi digunakan yang cocok dengan produksi pengidentifikasi dalam sintaks CSS. Di luar keyframe, secara umum at-rules CSS dicadangkan sebagian besar untuk konfigurasi tingkat yang lebih tinggi dan manipulasi style- atau stylesheet berdasarkan informasi "eksternal", yang berarti di luar gaya itu sendiri, seperti pengkodean karakter ( @charset ), atau menanggapi kondisi khusus perangkat ( @media ).

Selain itu, saya bisa memikirkan ide-ide yang lebih buruk. Seperti menggunakan at-rules untuk styling adalah salah satunya, menggunakan dua at-rules untuk fitur yang sama adalah hal lain. Tentu saja, itu semua tergantung pada tujuan Anda, jika Anda ingin memanipulasi gaya secara terprogram tanpa menyentuhnya secara pribadi, maka mungkin ada keuntungan menggunakan konstruksi tata bahasa yang lebih tumpul dan jelas yang mungkin lebih mudah diambil oleh parser. Sepertinya Anda menggunakan Stylus, jadi saya tertarik mendengar sudut pandang Anda tentang mengapa sintaks lain menguntungkan.

"extend sth" TIDAK sama dengan "match sth", itu tidak berarti apa-apa tentang struktur DOM yang seharusnya dipilih oleh pemilih.

Benar. Kelas semu dengan nth _sesuatu_ dijelaskan sebagai kelas semu " struktural " oleh spesifikasi CSS. Namun, ada 6 jenis kelas semu lainnya: "dinamis", "negasi", "target", "kosong", "status elemen UI" dan "bahasa". Jika spesifikasi CSS memang menggambarkan fitur "perpanjang", itu bisa duduk cukup elegan sebagai kategori antara kelas semu "negasi" dan "target".

Kelas semu memungkinkan pemilihan berdasarkan informasi di pohon dokumen, tetapi ini mungkin bukan penggunaan yang optimal dari fitur perluasan.

sangat salah

Komunitas yang lebih besar dari gabungan semua praprosesor lainnya tidak mungkin salah. Apa lagi yang bisa dikatakan?

@hax - Trolling tanpa berpikir bisa berubah menjadi diskusi yang terdidik jika Anda mengusulkan solusi Anda sendiri seperti orang lain di utas :extend . Setelah berminggu-minggu berbagai saran dan pertimbangan antara pengembang front-end yang sangat berpengalaman dan pengguna berat LESS, kami sampai pada solusi yang memuaskan dengan sintaks :extend . Jika Anda memiliki saran yang lebih baik, percayalah - kita semua adalah telinga.

Untuk menambahkan ke @jonschlinkert , .this:not(.that) { } dan .this:matches(.that) { } dan .this:extend(.that) { } sangat mirip. Yaitu: "Mengingat pemilih 'ini', hubungkan dengan pemilih 'itu' dengan cara tertentu." Karena KURANG sering memperluas konsep dan sintaks yang diperkenalkan di CSS, ini adalah ekstensi bahasa yang cukup logis. Kami memperhatikan spesifikasi CSS, dan sebagai hasilnya, mencerminkan keistimewaannya. Jika ada kejanggalan dalam konsepnya, mudah-mudahan dimulai dari CSS terlebih dahulu. Itu sebabnya dalam penjaga mixin kami, "DAN" diwakili oleh kata "dan", dan "ATAU" diwakili oleh koma: karena begitulah adanya dalam kueri media. Tujuan kami bukan untuk memperbaiki atau mengubah CSS, tetapi membuat CSS jauh lebih mudah untuk digunakan, dan untuk membuat KURANG benar-benar akrab bagi penulis CSS. :extend adalah contohnya. Jika Anda tahu cara menggunakan :not , Anda tahu cara menggunakan :extend .

Bagaimana jika kita menggunakan sintaks yang lebih "implisit" untuk menghindari parens bersarang dan untuk mempermudah perluasan mixin parametrik?

Hari ini, kami menggunakan mixin parametrik seperti ini:

.square {
  .border-radius(9px);
}

Daripada memperluas mixin seperti ini (karena Anda mungkin memperluas kelas normal):

.square {
  &:extend(.border-radius);
}

Kita bisa memperpanjang seperti ini:

.box {
  .border-radius:extend(9px);
}
.square {
  .border-radius:extend(9px);
}
.rectangle {
  .border-radius:extend(4px);
}

Perbedaannya adalah bahwa "extended mixin" diakhiri dengan titik koma dan menyatakan nilai atau nilai di dalam parens, .border-radius:extend(9px); , daripada mendaftar kelas untuk diperluas di dalam parens dan memulai blok pemilih baru dengan kurung kurawal, .border-radius:extend(.some-class) {} . IMHO, ini tidak kalah halus dari mixin implisit ( .border-radius; ), yang merupakan salah satu fitur terkeren KURANG, sekali lagi IMHO.

Dalam output yang dirender, "mixin parametrik yang diperluas" apa pun akan dirender di tempat mixin asli, seperti ini:

.box, 
.square {
    -webkit-border-radius: 9px;
    -moz-border-radius: 9px;
    border-radius: 9px;
}
.rectangle {
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
}
.some-other-class, 
.another-class, 
.and-another {
    -webkit-border-radius: 2px;
    -moz-border-radius: 2px;
    border-radius: 2px;
}

Jadi saya pribadi menyukai ini karena itu cukup menyimpang dari sintaks ekstensi "normal" di dalam blok pemilih untuk membuatnya cukup jelas tentang apa yang terjadi, dan itu sejalan dengan kehalusan konvensi yang ada di mana tidak perlu terlalu menjelaskan apa Anda coba capai dalam kode. Fitur ini pasti berada di bagian atas daftar keinginan pribadi saya.

Menggunakan contoh clearfix yang saya berikan dalam permintaan awal saya, seperti inilah tampilan sintaks saya yang direvisi:

.clearfix() {
    // ...
}
.navbar {
    .clearfix:extend(); // instead of &:extend(.clearfix());
}
.banner {
    .clearfix:extend();
    &:extend(.some-class); // "implicit mixin" being extended
}

Saya suka ke mana Anda pergi dengan ini. Saya pikir pendekatan yang lebih ramah adalah dengan menggunakan :extend di akhir sintaks mixin _existing_ seperti ini:

.box {
  .border-radius(9px):extend;
}
.square {
  .border-radius(9px):extend;
}
.rectangle {
  .border-radius(4px):extend;
}

Sesuatu tentang menghilangkan parens setelah :extend membuat jika terasa seperti melayani tujuan yang berbeda dari sintaks perluasan yang ada.

Saya bisa melakukannya dengan cara apa pun, tetapi saya lebih suka .border-radius:extend(9px); karena konsisten dengan sintaks ekstensi, IMO masih jelas bahwa ini adalah mixin, tetapi juga menyiratkan bahwa parameter/nilai sedang diperpanjang - yang akan membantu menjelaskan mengapa output "dikelompokkan".

@jonschlinkert - pada titik ini saya sangat menghargai pendapat Anda dan akan mendukung keputusan apa pun yang menurut Anda terbaik. Saya akan mengatakan bahwa metode Anda terasa seolah-olah 9px diteruskan ke "memperpanjang" sebagai lawan diteruskan ke mixin itu sendiri ... tapi saya baik-baik saja dengan keduanya.

@DesignByOnyx terima kasih atas kata-kata yang baik. Apa yang Anda katakan sangat masuk akal, "lensa" ekstensi saya (dalam Kurang) adalah seperti:

.this:extend(.that) {}

jadi maksud anda konsisten dengan pandangan saya sendiri. @matthewdl atau @lukeapage apakah salah satu dari Anda memiliki pandangan/pendapat tentang ini? Saya pikir kedua sintaks dapat berfungsi (dan mungkin yang lain), tetapi memang saya belum fokus pada "pemeriksaan masa depan" dengan salah satu sintaks, jadi mungkin ada beberapa gotcha di keduanya. Saya hanya ingin melihat ini terjadi, saya pikir memperluas mixin adalah fitur yang menarik untuk Less, itu akan berbuat lebih banyak untuk menghasilkan kode KERING daripada fitur lain yang dapat saya pikirkan saat ini

Mengapa kompiler Less tidak dapat secara otomatis "melakukan hal yang benar"? Dengan kata lain, jika mixin ini dideklarasikan dalam kode saya:

.someMixin {
    color: red;
}

Dan kemudian saya menggunakannya seperti ini:

#someElement {
    .someMixin;
}

Mengapa kompiler tidak cukup pintar untuk mengoptimalkan kode Less ini ke dalam CSS ini:

.someMixin,
#someElement
{
    color:red;
}

Mengapa saya, sebagai pengguna, harus menambahkan kata kunci :extends secara manual untuk mendapatkan perilaku ini? Kompiler harus cukup pintar untuk menyadari bahwa pengoptimalan ini dapat dilakukan dan kemudian melakukannya.

Secara pribadi, saya pikir ide :extends ini membingungkan. Seluruh pengertian dari kata kunci "memperluas" berarti: "Ambil benda ini X dan tambahkan A, B, dan C padanya." Tetapi dalam konteks ini, Anda mengusulkan untuk mendefinisikan ulang meluas ke: "Benda X ini sebenarnya sama dengan Y, jadi Anda bisa mendeklarasikan Y dan X sama dan menulisnya sekali." Ini bertentangan dengan gagasan standar tentang "memperluas" sesuatu.

Ya, saya memikirkan hal yang sama persis sebelumnya dan akan mempostingnya, tetapi setelah memikirkannya memutuskan bahwa secara otomatis menerapkan "perpanjang perilaku" ke mixin terlalu keras untuk Less.js. Secara khusus, meskipun pewarisan pemilih (memperpanjang) adalah konsep luar biasa yang sangat bermanfaat untuk pengurangan kode, sebagian besar keluhan yang saya baca tentang fitur tersebut adalah ia menambahkan lapisan abstraksi yang membuatnya sulit untuk menyisir kode dan debug ketika ada masalah.

Begitu banyak pikiran yang berpikiran sama, tetapi saya memilih ide itu secara pribadi karena a) kita tidak boleh mengacaukan mixin "normal" sama sekali sampai fitur extend benar-benar stabil dan spesifikasinya lebih lengkap, b) Saya pikir banyak pengembang ingin membuat panggilan ini untuk diri mereka sendiri, dan c) seringkali hal-hal tampak begitu jelas dan kering, ketika faktanya adalah bahwa kita melupakan banyak keanehan tentang mixin yang akan membuat Anda saran sulit untuk diterapkan minimal, dan mungkin tidak mungkin untuk diterapkan sementara masih memungkinkan pengembang untuk menggunakan semua "peretasan mixin" yang telah kami... ahem, mereka telah mengenal dan menyukai.

Sintaks :extends() masih merupakan peretasan yang cukup canggung yang tidak intuitif dan sulit dijelaskan kepada pengguna baru.

Solusi yang lebih baik adalah membuat kompiler secara otomatis mengoptimalkan CSS seperti yang dijelaskan di atas ketika pengguna telah memilih gaya keluaran yang sesuai (dikompresi, dioptimalkan, dll). Jika pengguna memilih gaya keluaran yang tidak terkompresi, maka kompiler harus menghindari pengoptimalan ini dan menghasilkan lebih sedikit kode KERING.

Plus, Anda dapat mengatasi kesulitan debugging dengan peta sumber. Mereka dapat dengan mudah menunjukkan lokasi CSS yang dikompilasi yang berasal dari mixin Less.

@bdkjones tolong buat permintaan fitur baru untuk "mengoptimalkan CSS secara otomatis" dengan saran Anda tentang cara melakukannya dalam kode. Masukan seperti ini selalu diterima.

Poin diambil! Saya tidak bermaksud terlalu keras dalam komentar terakhir saya; Saya kadang terbawa suasana.

Adapun kode, saya khawatir saya benar-benar sibuk dengan CodeKit. Saya membiarkan kalian mengeluarkan bahasa!

Sama sekali tidak! sungguh, saya melihat Anda terlibat dengan CodeKit, akan sangat senang jika Anda terus memberikan masukan. Tidak semua fitur akan menyenangkan semua orang, tetapi umpan balik dan opini yang kuat adalah satu-satunya hal yang membuat roda terus berputar!

@bdkjones Masalahnya adalah kaskade. Dalam kasus penggunaan Anda, ini berfungsi, tetapi pengelompokan pemilih tidak akan memiliki hasil yang diinginkan dalam semua kasus, karena itu mungkin akan memindahkan penyeleksi "lebih awal" dalam dokumen yang mencegah deklarasi yang menimpa pemilih tersebut.

Tapi, saya setuju dengan pernyataan Anda terhadap sintaks mixin extend seperti yang telah berkembang di sini. Selector X harus memperluas Selector atau mixin Y, jadi ini tampak aneh:

.border-radius(9px):extend;

Saya pikir kami menyalahgunakan sintaks ekstensi. Jika sintaks ekstensi seperti yang ada tidak cocok dengan mixin (yang sangat masuk akal), saya sarankan kita menemukan sintaks yang tepat untuk mixin, daripada memperluas sintaks ekstensi dengan cara yang merusak metafora, seperti yang ditunjukkan @bdkjones keluar.

Saya pikir kami menyalahgunakan sintaks ekstensi

saya tidak setuju. Jika berhasil, gunakan. Mengapa membuat sintaks baru tanpa alasan? Saya pikir kami memiliki preseden yang bagus untuk sintaks yang diusulkan, saya memberikan banyak contoh dan alasan pendukung di balik saran saya, tetapi pendapat Anda tentang sintaks yang diusulkan tampaknya sangat subjektif. Dan karena Anda telah membuat pernyataan itu beberapa kali baru-baru ini, dapatkah Anda menjelaskan mengapa menurut Anda sintaks tersebut disalahgunakan? Atau jelaskan pada titik mana sintaks disalahgunakan? Atau bagikan pemikiran Anda tentang bagaimana mixin harus diperluas, tetapi tanpa sintaks "perpanjang"?

Dalam kasus penggunaan Anda, ini berfungsi, tetapi pengelompokan pemilih tidak akan memiliki hasil yang diinginkan dalam semua kasus, karena itu mungkin akan memindahkan penyeleksi "lebih awal" dalam dokumen yang mencegah deklarasi yang menimpa pemilih tersebut.
...
Saya pikir kami menyalahgunakan sintaks ekstensi. Jika sintaks ekstensi seperti yang ada tidak cocok dengan mixin (yang sangat masuk akal), saya sarankan kita menemukan sintaks yang tepat untuk mixin, daripada memperluas sintaks ekstensi dengan cara yang merusak metafora, seperti yang ditunjukkan bdkjones .

Tidak. Dia tidak menunjukkan apa-apa, dia mendesak kita untuk membuat Less lebih mudah digunakan - itulah intinya. Cara yang disarankannya untuk melakukan itu salah arah, tetapi tujuannya baik. Apa yang tidak dia pikirkan adalah kaskade yang baru saja Anda tunjukkan. Saat menggunakan perpanjangan secara umum, Anda harus memperhitungkan kaskade. Saya pikir siapa pun yang menggunakan extend alih-alih mixin menyadarinya. Jadi, itulah mengapa Less.js menawarkan Anda pilihan untuk menggunakannya saat masuk akal, atau _tidak_ saat tidak. Fakta bahwa "C" pertama dalam CSS adalah singkatan dari cascading tidak meniadakan keuntungan dari mengkonsolidasikan gaya duplikat ketika cascade tidak material. Apa yang kulewatkan di sini?

Jadi bisakah Anda mengklarifikasi sentimen Anda? Apakah Anda menentang fitur ini, atau sintaksnya? Jika Anda menentang sintaks, silakan usulkan sesuatu yang lain untuk membuat semuanya tetap berjalan, jika tidak, jangan menghalangi kemajuan fitur yang menjanjikan untuk bahasa ini.

Apakah Anda menentang fitur ini, atau sintaksnya?

Saya untuk fitur, tentu saja. Ini adalah arah yang jelas. Saya meninjau sintaks lagi di utas ini. Beberapa pemikiran:

Pertama, ini canggung bagi saya:

.something:extend( .clearfix() ) { }

Tanda kurung ganda hanya aneh. Tapi, ini adalah adopsi yang setia dari sintaks ekstensi yang ada, jadi cukup adil. Jadi, itu sebabnya saya menganjurkan sesuatu yang lain, mungkin sesuatu selain memperluas.

Lalu ada yang Anda usulkan, saya pikir untuk alasan yang sama:

.border-radius(9px):extend;

...yang membuat saya alergi, karena tampaknya bertentangan dengan spesifikasi perluasan yang ada. Jadi di situlah sepertinya penyalahgunaan bagi saya.

TETAPI

Saya menyadari sebenarnya ada dua pilihan di sana. Salah satunya adalah kami melakukan sesuatu yang berbeda untuk mixin. Tetapi opsi lainnya adalah kami merevisi spesifikasi perluasan yang ada, untuk semua hal, termasuk mixin, seperti:

#namespace {
  .box-template {
    .subelement {
      // we'll add the all flag to extend everything here
    }
  }
}
.clearfix() {
  // a clearfix mixin
}
.text-shadow(@shadow) {
  -moz-text-shadow: @shadow;
  text-shadow: @shadow;
}
.some .random .selector {
  // with properties
}
.mybox {
  .clearfix:extend;
  #namespace > .box-template:extend !all;
  .text-shadow:extend(2px 2px #ff0000);
  .some .random .selector:extend;
}

Tapi.... dengan pemilih penuh ( .some .random .selector ), itu mulai salah membaca. Sepertinya hanya .selector yang memiliki ekstensi di atasnya. Dan kata "memperpanjang" mulai hilang, padahal itu adalah kata penting dalam deklarasi ini. Ini tidak terjadi ketika ditulis sebagai &:extend() (karena muncul di awal), tetapi sintaks itu tampaknya rusak dengan mixin.

Jadi, saya akan mengusulkan salah satu opsi ini:

// Migrating existing syntax, but ommitting a parens requirement when used with &:

.mybox {
  &:extend .clearfix;
  &:extend #namespace > .box-template !all;
  &:extend .text-shadow(2px 2px #ff0000);
  &:extend .some .random .selector;
}

// Adopting something similar to the SASS approach

.mybox {
  <strong i="24">@extend</strong> .clearfix;
  <strong i="25">@extend</strong> #namespace > .box-template !all;
  <strong i="26">@extend</strong> .text-shadow(2px 2px #ff0000);
  <strong i="27">@extend</strong> .some .random .selector;
}

Saya pikir diskusi tentang memperluas mixin dan kueri media telah menyoroti bahwa pendekatan sintaks asli kami ke :extend tidak begitu fleksibel, terutama ketika kami ingin memperluas banyak pemilih & mixin.

Saya pikir penting untuk mendapatkan :extend right. Jika kita ingin menggunakan "extend" untuk mixin, maka menurut saya kita harus merevisi sintaks ekstensi.

Saya tidak mengusulkan .border-radius(9px):extend; , @DesignByOnyx melakukannya. Saya mengusulkan .border-radius:extend(9px);

Tetapi kedua sintaks baik-baik saja dengan saya. Atau kita bisa melakukan .border-radius(9px) !extend; atau .border-radius:shamallamadingdongscoobiedoo(9px):extendmyass (jk), itu tidak masalah bagi saya karena tidak ada yang berubah dengan perilaku mixin atau perluasan sama sekali.

Jadi saya tidak yakin bagaimana Anda datang dengan kebutuhan untuk melakukan semua itu, Anda mungkin terlalu memperumit hal-hal untuk diri sendiri.

Permintaan fitur ini secara tegas tentang memiliki kemampuan untuk menyalin properti yang diwarisi dari mixin _ke tempat mixin_, dan akan mengikuti aturan yang telah ditetapkan dengan baik dengan perilaku mixin saat ini, dan sekarang juga memiliki prioritas dengan dan perilaku yang identik dengan fitur <strong i="14">@import</strong> (reference) (yang, btw, saya telah menggunakan cukup banyak dalam latihan dan cinta). Pendeknya:

• Saat Anda menggunakan mixin, propertinya disalin ke tempat pemilih yang memanggil mixin.
• Saat Anda menggunakan perluasan, pemilih _extending_ akan disalin ke tempat kelas _extended_.
• Jadi, ketika Anda memperluas mixin, pemilih panggilan akan disalin ke tempat mixin.

Saya tidak yakin mengapa Anda bahkan ingin mengulangi perdebatan tentang sintaks untuk diperpanjang setelah dua tahun perdebatan, > 100 posting, banyak penelitian dan kasus telah dibuat bahwa itu _jauh lebih_ fleksibel daripada @extend .

Btw, saya tidak yakin apa yang Anda maksud di sini:

dengan pemilih penuh (.some .random .selector), ia mulai salah membaca. Sepertinya hanya .selector yang memiliki ekstensi di atasnya. Dan kata "memperpanjang" mulai hilang, padahal itu adalah kata penting dalam deklarasi ini.

Saya tidak setuju bahwa itu membingungkan, karena begitulah cara kerjanya sekarang. Bukankah itu seperti mengatakan "pengembang CSS tidak tahu cara kerja penyeleksi yang dikelompokkan"? Bagaimana dengan :hover atau :after ? Saya pikir pengembang CSS dapat memahami ini dengan baik, karena cara kerjanya sama seperti pseduo lainnya.

.some .random .selector:extend(.something) {}

Saya suka fleksibilitas yang diberikan ini, karena saya dapat (atau keduanya) menerapkan perluasan ke pemilih, yaitu .some .random .selector , bukan .selector , atau saya dapat memasukkannya ke dalam blok pemilih.

Saya pikir diskusi seputar perluasan mixin dan kueri media

Saya menutup masalah kueri media karena saya menyadari itu bisa diselesaikan dengan memperluas mixin. "Semua jalan menuju _____" memperluas mixin. ;-)

Saya ingin memberikan dua sen saya mengatakan bahwa parens di dalam parens - :extend( .some-mixin() ) - tidak terlalu mengganggu saya, terutama karena :extend( .some-selector ) sudah ditetapkan dan telah dibahas sehingga membuat mual. Saya setuju bahwa parens ganda tidak ideal dengan cara apa pun dan itu _tidak_ terasa agak aneh. Tetapi saya merasa bahwa penting agar mixin dan penyeleksi diperlakukan sama dalam hal "memperpanjang", sama seperti mereka diperlakukan sama di Less klasik:

header {
    .some-selector;
    .some-mixin;
    .some-mixin();
}

Karena itu, saya tidak merasa terlalu buruk (atau terbatas) dengan melakukan ini:

header {
    &:extend( .some-selector );
    &:extend( .some-mixin );
    &:extend( .some-mixin() );
}

Tetapi saya merasa bahwa penting agar mixin dan penyeleksi diperlakukan sama dalam hal "memperpanjang", sama seperti mereka diperlakukan sama di Less klasik

Saya berada di halaman yang sama pada saat itu.

Saya tidak yakin mengapa Anda bahkan ingin mengulangi perdebatan tentang sintaks untuk diperpanjang setelah dua tahun berdebat,> 100 posting

Ini bukan masalah ingin. Tidak, saya tidak mau. Namun pada saat itu, kami mengocok mixin untuk ditangani nanti. Saya hanya ingin mengajukan pertanyaan apakah kami yakin sintaks ini berfungsi seperti yang kami inginkan untuk semuanya. Tidak ada salahnya meninjau kembali pertanyaan jika kita merasa itu tidak berhasil atau tidak elegan untuk beberapa kegunaan. KURANG telah ada sejak lama tanpa perpanjangan. Lebih penting untuk melakukannya dengan benar daripada menyelesaikannya dengan cepat.

Jadi, kita baik-baik saja dengan ini?

.mybox {
  &:extend(.clearfix());
  &:extend(#namespace > .box-template all);
  &:extend(.text-shadow(2px 2px #ff0000));
  &:extend(.some .random .selector);
}

parens di dalam parens - :extend( .some-mixin() ) - tidak terlalu mengganggu saya, terutama karena :extend( .some-selector ) sudah dibuat

Ya benar, dan faktanya kita sudah memiliki preseden untuk parens ganda di Less.js juga, DAN dengan sintaks ekstensi yang ada. Dan preseden yang telah ditetapkan tidak semudah yang kami sarankan dengan mixin. Saat ini, kita dapat melakukan ini:

.one:nth-child(5) {
  color: red;
}
// We can extend psuedos
.two:extend(.one:nth-child(5)) {
  background: blue;
}
// And attributes
.two:extend(.one, [hidden]) {
  width: 2px;
}

Anda bahkan akan menemukan parens bersarang dalam sintaks CSS yang ada .

Jadi di sini kita memiliki sintaks _nested parens_ dan _nested pseudo-class_. Dan saya tidak punya masalah dengan itu, itu jelas IMO.

Jadi saya setuju dengan @DesignByOnyx , itu adalah proposal asli saya dan tampaknya tidak disukai orang lain karena suatu alasan, jadi saya mencoba mencari sintaks lain. Tapi saya hanya menggunakan sintaks mixin lama biasa tepat di dalam parens ekstensi.

Faktanya, sintaks asli akan memungkinkan beberapa kelas atau mixin yang dipisahkan koma untuk diperluas.

.banner {
    &:extend(.clearfix(), .border-radius(4px), .alert, .navbar-fixed-top, [hidden]); 
}

Itu melakukan pekerjaan, dan itu ketat. Tidak ada keluhan di sini.

Jadi, kita baik-baik saja dengan ini?

ya. sama sekali. Itu sudah seperti itu di CSS. Jadi saya baik-baik saja dengan itu.

ya. sama sekali. Itu sudah seperti itu di CSS. Jadi saya baik-baik saja dengan itu.

JADI HARUS DATANG UNTUK LULUS.

Pertanyaan, saya rasa saat ini kami tidak memiliki dukungan untuk beberapa penyeleksi di :extend, jadi saya ingin tahu di mana kata kunci "semua" akan cocok dalam format itu, tetapi itu mungkin harus menjadi bagian dari masalah terpisah.

Anda telah membuat kasus Anda, Tn. Schlinkert. Anda harus pergi ke hukum. ;)

Saya tidak berpikir kami saat ini memiliki dukungan untuk banyak pemilih di :extend

Tapi kami melakukannya ;-) Saya telah melakukannya secara ekstensif. Baru saja melakukan ini sebelumnya:

.global-nav {
  // Extend and override bootstrap styles
  &:extend(.navbar, .navbar-fixed-top all, .navbar-inverse); // this works, and it's pretty handy
  &.hidden:extend(.navbar.hidden) {}
  &.visible:extend(.navbar.visible) {}
  &:hover {
    background: lighten(@brand-primary, 5%);
  }
  .navbar-brand {
    padding-left: 20px; 
  }
  .navbar-nav > .active > a {
    &, &:hover, &:focus {
      background-color: darken(@brand-primary, 5%);      
    }
  }
}

Anda telah membuat kasus Anda, Tn. Schlinkert. Anda harus pergi ke hukum. ;)

Pfft, lol oh hentikan kamu!

Saya hanya ingin menambahkan bahwa menurut saya sintaks ini:

.foo {
  &:extend( .bar() );
}

bagus. Saya tidak menemukan tanda kurung canggung sama sekali.

Tapi terutama saya hanya ingin kalian cepat jadi saya bisa melakukan semua hal keren yang saya kerjakan di SASS di preprocessor favorit saya :D

Terima kasih atas tanggapan Anda, @mgerring !

+1 Menunggu fitur ini. Pertahankan kerja bagus :)

Ke pos asli:

.clearfixed {
   // stuff
}
.clearfix() {
    &:extend(.clearfixed);
}
.navbar {
  .clearfix();
}
.banner {
  .clearfix();
}

Mungkin ini tidak berhasil pada saat posting? Tetapi itu menghasilkan sesuatu yang sangat dekat dengan apa yang Anda inginkan:

.clearfixed,
.navbar,
.banner {
  // stuff
}

@aaronmw , Ya, tentu saja contoh Anda melakukan hal yang sama, tetapi poin kunci dari proposal ini adalah kemampuan untuk memperluas mixin yang ditentukan di tempat lain (yaitu ketika Anda tidak dapat atau tidak ingin memodifikasi mixin itu sendiri, misalnya file lain, dibagikan perpustakaan dll)

Ya, per poin @seven-phases-max, ini bisa dilakukan seperti yang Anda gambarkan, tetapi itu tidak idiomatis.

Benar — maaf, saya sudah membaca lebih banyak tentang utas ini sekarang dan melihat apa yang kami tuju. Kelas "kerangka" yang saya gunakan hanyalah sampah dalam output yang dikompilasi karena kelas .clearfixed tidak akan pernah secara eksplisit dirujuk di luar mixin. &:extend(.clearfix()) masuk akal bagi saya sekarang, dan cukup menarik. Untuk saat ini, saya akan menangani kelas kerangka yang mengotori CSS saya.

Diskusi hebat di sini!

:+1:

Jadi kapan kita bisa mengharapkan fitur ini? Ini cukup berguna untuk konsep seperti OOCSS untuk membuat konstruksi seperti "kelas abstrak".

• putuskan bagaimana kita mengatasi nesting/scope dan mixin vs kelas normal misalnya

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {}  //
.b:extend(.a) {}  // and if so is the output wrapped by #thing?
.b:extend(.a()) {}  // do I need special format to say extend only that mixin?

• apakah kita menangani argumen? apakah kita menggabungkan mixin dengan argumen yang sama?
• ubah ke-css-visitor untuk tidak menghapus definisi mixin
• dapatkan pengunjung yang diperluas untuk mengunjungi definisi mixin dan buat set aturan baru dengan kelas baru

Saya pikir bagian tersulit sebenarnya adalah memutuskan _exactly_ bagaimana seharusnya bekerja.

putuskan bagaimana kita mengatasi nesting/scope dan mixin vs kelas normal misalnya

Saya akan mencoba menafsirkan ekstensi mixin dengan cara ini:
.b:extend(.a(1, 2, 3)) {} harus berperilaku sama dengan membuat mixin non-parametrik anonim (yaitu pemilih sederhana) dalam lingkup 'b' yang memanggil .a(1, 2, 3) di dalam dan kemudian diperluas dengan cara biasa, yaitu ini:

.a(<strong i="11">@a</strong>, <strong i="12">@b</strong>, @c) {
    // ...
}

.b:extend(.a(1, 2, 3)) {}

harus sama dengan ini:

.a(<strong i="16">@a</strong>, <strong i="17">@b</strong>, @c) {
    // ...
}

#__anon_a_1_2_3 {.a(1, 2, 3);}

.b:extend(#__anon_a_1_2_3) {}

kecuali #__anon_a_1_2_3 tidak muncul di output. Saya pikir pendekatan seperti itu harus membuatnya kurang atau lebih mudah tanpa menciptakan aturan khusus.

Jadi dengan menerapkan konsep di atas ke contoh #thing .a kita mendapatkan yang berikut:

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {} // since we do ignore parens on mixin call and have ...
// no plans changing this (?), it should probably create .b {color: black} 

.b:extend(.a) {}  // there's only one .a in this scope so it's -> .b {color: green}

.b:extend(.a()) {}  // same as above -> .b {color: green}

Di sisi lain, "parens opsional" adalah hal yang cukup kecil dari sudut pandang praktis, jadi mungkin juga boleh untuk membuatnya lebih ketat dan memerlukan parens untuk mixin parametrik di dalam extend (tidak ada tekanan pada extend untuk mewarisi sintaks panggilan mixin biasa karena bagaimanapun juga tidak akan sepenuhnya kompatibel).

apakah kita menggabungkan mixin dengan argumen yang sama?

Idealnya ya, jika tidak maka semuanya akan menjadi tidak berguna misalnya:

.b:extend(.a()) {}
.c:extend(.a()) {}

harus membuat:

.b, .c {color: green}

Hmm, sepertinya penggabungan akan menjadi hal yang paling sulit untuk diterapkan.

Masalah lain adalah ruang lingkup, seperti yang baru-baru ini muncul di # 1730, mixin menggunakan jalur ruang lingkup 'relatif' dan perluasan menggunakan 'mutlak', jadi kami mendapatkan semacam konflik saat menggabungkan keduanya:

.div {color: green}

body {
   .div {color: red}

   p-a       {.div()}    // -> body p-a {color: red}
   p-b:extend(.div)   {} // -> body p-b {color: green}
   p-c:extend(.div()) {} // -> ???
}

Dan bahkan lebih membingungkan jika kita menulis ulang contoh ini dengan mixin parametrik.

Saya ingin menawarkan dua sen saya untuk mengatakan bahwa ini mungkin saat yang tepat untuk mundur dan mengatakan "bagaimana seharusnya memperluas mixin digunakan" - dan saya pikir @donaldpipowitch benar mengatakan bahwa itu membawa sedikit kemampuan OOCSS . Karena itu, saya tidak berpikir kita harus terlalu terjebak dalam bagaimana sub-kelas ("properti", jika Anda mau) akan diperluas dari dalam kelas itu sendiri. Jadi misalnya, pengguna akan memiliki "kelas" (komponen) tertentu dengan "properti" (pemilih bersarang):

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
}

Saya tidak berpikir kita harus fokus pada situasi di mana pengguna ingin melakukan hal berikut:

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
    .tail:extend( .leg() ) { 
        .toes { display:none; } 
    }
}

Ini bukan hanya skenario kasus pinggiran IMO, tetapi pengguna harus menulis gayanya seperti ini:

.dog() {
    .leg, .tail { ... }
    .ears { ... }
    .fur { ... }
    .tail .toes { display:none; }
}

Kasus penggunaan 99,8% untuk memperluas mixin adalah untuk memungkinkan pengembang memiliki perpustakaan KURANG besar mereka yang penuh dengan gaya yang telah mereka kumpulkan selama bertahun-tahun. Perpustakaan besar ini akan penuh dengan hal-hal seperti:

.clearfix() { ... }
.modal() { ... }
.alert-box() { 
    &:extend( .modal() ); 
    &.message { ... } 
    &.warning { ... } 
    &.error { ... } 
}
.grid-wrap() { ... }
.form-input() { ... }
.form-select() { ... }
.button( <strong i="16">@bgColor</strong>, <strong i="17">@textColor</strong> ) { ... }
[... thousands more like this ...]

Dan mereka bisa fokus pada gaya penulisan:

.page-wrap:extend( .grid-wrap(), .clearfix() ) { ... }
input[type="text"]:extend( .form-input ) { ... }
textarea:extend( .form-input() );

Mereka bahkan dapat melakukan ini, jika mereka mau dan tidak ada gaya "modal" yang akan ada di hasil akhir karena tidak digunakan dalam proyek ini:

.inline-error:extend( .alert-box.error )

Ya, saya merasa @DesignByOnyx ada benarnya. Saya tidak berpikir ada yang salah dengan mencari tahu hal-hal yang lebih kompleks nanti. Bahkan, saya pikir untuk saat ini yang terbaik adalah mengimplementasikan perluasan _just non-parametric_ mixin terlebih dahulu. Itu akan mencakup mungkin 80 – 90% dari semua kasus penggunaan (memungkinkan struktur berorientasi objek lebih ke stylesheet, dll.). Segala sesuatu yang lain bisa menunggu satu atau dua tambalan, imo.

@DesignByOnyx dan @calvinjuarez kita tidak bisa mengetahuinya nanti.. itu harus dikodekan dengan satu atau lain cara. Jika kita melompat pada solusi dan kemudian memutuskan untuk mengubahnya nanti, kita memperkenalkan perubahan yang melanggar, yang tidak baik.

jika kami dapat menemukan pendekatan yang tidak mendukung skenario pinggiran, saya lebih dari senang, itulah yang akhirnya kami lakukan dengan dukungan perluasan utama (dapat diperluas dengan lebih banyak kata kunci, jika perlu), tapi kita perlu rencana untuk apa yang didukung dan bagaimana.

@seven-phases-max dalam nada di atas, saya akan dengan senang hati mengabaikan mixin parametrik untuk saat ini.

Hmm, sepertinya penggabungan akan menjadi hal yang paling sulit untuk diterapkan.

• tapi menyatu? Saya akan menggunakan pendekatan yang sama dengan ekstensi yang ada, misalnya menemukan kecocokan dan menambahkannya .. jadi itu tidak digabungkan dengan menempatkan kedua ekstensi ke tempat ke-3, mixin, yang kemudian dikeluarkan sebagai spesial kasus di genCSS-nya

Saya juga berpikir contoh kedua @seven-phases-max over scope kemungkinan besar akan mempengaruhi seseorang - Anda hanya perlu mixin dan mixin parametrik kosong dengan nama yang sama.

@lukeapage :+1: Benar, saya bisa menggali itu. Panggilan yang bagus.

Sebenarnya, saya pikir @seven-phases-max sudah benar. Jadi :+1: ada juga.

@lukeapage - Saya tidak mencoba menganjurkan jenis solusi "satu atau lain cara" melainkan pendekatan yang (seperti yang Anda katakan) tidak mendukung kasus pinggiran. Faktanya, kami telah melewati kemampuan untuk lingkup "lokal" dan telah memasuki fase IMO "terlambat untuk kembali" karena :extend bekerja seperti ini:

.block { color: green; }

.component {
  .block { color: red; }    
  div:extend( .block ) {};
}

/*
.block,
.component div {
  color: green;
}
.component .block {
  color: red;
}
*/

Saya tidak melihat alasan mengapa kode berikut harus bekerja secara berbeda dari yang di atas - manfaatnya adalah tidak ada kelas .block dalam hasil akhir:

.block() { color: green; }

.component {
  .block() { color: red; }  
  div:extend( .block() ) { };
}

/*
.component div {
  color: green;
}
*/

Btw., ada sedikit penyimpangan dalam konvensi penamaan kami :) misalnya bagi saya "mixin parametrik" berarti mixin apa pun yang didefinisikan dengan parens, termasuk yang memiliki parameter 0 (yaitu .mixin() {} adalah "parametrik"). Dan mixin "non-parametrik" hanyalah pemilih sederhana (yaitu .mixin {} ). Sejauh ini saya kira penyimpangan ini tidak menimbulkan kesalahpahaman (misalnya dalam sebagian besar contoh di atas jelas dari konteks jika .mixin() {} disebut sebagai mixin "non-parametrik"), tetapi...
Jangan lewatkan bahwa dalam dokumen pemilih sederhana dinamai "mixin" juga (segera setelah dicampur) dan itu juga merupakan mixin "non-parametrik" berdasarkan desain. Jadi merujuk ke .mixin() {} sebagai "non-parametrik" semata-mata mungkin cukup ambigu (Secara teknis perbedaannya adalah ada atau kurangnya tanda kurung definisi dan bukan pada jumlah argumen).
Oke, ini boo-boo-boo saya yang biasa. :)

@lukeapage

Saya akan dengan senang hati mengabaikan mixin parametrik untuk saat ini.

Yaitu tidak mendukung perluasan untuk mixin dengan parameter bukan nol? Saya baik-baik saja dengan itu. Saya hanya mencoba memperkirakan bagaimana hal itu dapat diterapkan (secara terpadu tanpa membatasi mixin parameter nol dan bukan nol, sehingga itu tidak akan menjadi penghenti pertunjukan ketika/jika yang terakhir melompat pada akhirnya).

tapi menyatu? Saya akan menggunakan pendekatan yang sama dengan ekstensi yang ada, misalnya menemukan kecocokan dan menambahkannya..

Benar, saya kira di sana saya lebih memikirkan kemungkinan kesulitan dengan penggabungan ekstensi mixin dengan argumen aktual.: misalnya:

.b:extend(.a(1, 2, 3)) {}
.c:extend(.a(1, 2, 3)) {}

Di sisi lain saya curiga ada kejutan tersembunyi dengan mixin parameter nol juga, misalnya:

.a {color: red}
.a {width: 2px}

.b:extend(.a) {}   // creates two `.b` blocks (it is expected since there're two `.a` blocks anyway)

.c {.a}            // creates one `.c` block (OK, this is just how mixins work)

.d() {color: blue}
.d() {width: 10px}

.e {.d()}          // creates one `.e` block (OK, this is just how mixins work)

.f:extend(.d()) {} // tada! another room for complains if this creates two `.f` blocks :)

Yah, mungkin ini terlalu dalam (dan juga terlalu kecil untuk diperhatikan saat ini).

.f:extend(.d()) {} // tada! another room for complains if this creates two .f blocks :)

Dengan pemikiran bahwa "karena, dalam contoh ini, .d() adalah parametrik, seharusnya tidak membuat dua blok .f "?

Ya, saya mengerti maksud Anda, mengingat mixin akan menghasilkan:

.f {
  color: #0000ff;
  width: 10px;
}

IMHO Jika masuk akal untuk melakukannya dalam langkah-langkah mungkin hanya menjelaskannya, tetapi saya tidak akan _tidak_ mengimplementasikan sesuatu untuk menghindari keluhan itu sendiri. Tentu saja, ini hanya 2c saya. Dan jika diimplementasikan dengan perilaku yang Anda jelaskan, Anda dapat - pada saat menambahkan fitur - juga membuat permintaan fitur untuk "menggabungkan blok CSS dari pemilih yang diperluas", hanya untuk menghindari keluhan...?

tetapi saya tidak akan menerapkan sesuatu untuk menghindari keluhan itu sendiri.

Saya sangat setuju. Saya hanya mencoba memprediksi kejutan apa pun yang bisa menjadi salah satu dari "terlambat untuk berubah" lebih jauh.

:+1: ya, saya suka cara Anda berpikir!

Saya suka bahwa diskusi ini masih berlangsung. Mari saya kembali ke beberapa poin dari diskusi ini. Pertama, sejauh penggunaan umum, ini sudah sama.

.mixin {} == .mixin() {}

Dengan pengecualian bahwa .mixin {} mendapatkan output sebagai kelas. Saya tahu di parser mereka mungkin diperlakukan berbeda, tetapi dalam penggunaan, mereka membuang pasangan properti/nilai.

Arti:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    .mixin1;
    foo:bar;
}
.use2 {
    .mixin2;
    foo:bar;
}

Karena riwayat sintaksis Kurang ini, masuk akal bahwa saya dapat melakukan ini:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use2 {
    &:extend(.mixin2);
    foo:bar;
}

Bagi saya, itu tidak kontroversial, seperti yang sering kita bicarakan :extend sebagai pengganti drop-in dari banyak contoh penggunaan mixin asli.

Untuk orang awam, ini mungkin akan identik secara intuitif, karena .mixin1 secara historis dapat direferensikan dengan cara berikut, baik ditulis dengan tanda kurung atau tidak:

.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}

Jadi, saya mengharapkan ini:

.mixin1() {
    color: red;    
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}
.use2 {
    &:extend(.mixin1());
    bar:foo;
}

...untuk mengeluarkan...

.use1, .use2 {
    color: red;    
}
.use1 {
    foo:bar;
}
.use2 {
    bar:foo;
}

Jika mixin didefinisikan dua kali, itu akan diganti dua kali saat diperpanjang, seperti saudara perempuannya, pemilih kelas.

.mixin1() {
  color: red;
}
.mixin1() {
  width: 30px;
}
.use1 {
  &:extend(.mixin1);
  foo: bar;
}
.use2 {
  &:extend(.mixin1);
}
//output

.use1, .use2 {
  color: red;
}
.use1, .use2 { 
  width: 30px;
}
.use1 {
  foo: bar;
}

Pada dasarnya itulah cara kerja perluasan sekarang jika Anda menghapus tanda kurung pada definisi mixin, kecuali, tentu saja, bahwa nama mixin akan muncul di output, jadi masuk akal untuk mengikuti perilaku perluasan yang ada.

Dengan parameter (kasus penggunaan 90% saya), hal yang sama, kecuali mereka dibedakan oleh input:

.col(@width) {
  width: @width;
  display: table-cell;
}

.col1:extend(.col(10%)) { }
.col2:extend(.col(10%)) { }
.col3:extend(.col(80%)) { }

//output 

.col1, .col2 {
  width: 10%;
  display: table-cell;
}
.col3 {
  width: 80%;
  display: table-cell;
}

Bagi saya, alasan untuk memperluas mixin adalah untuk mengelompokkan parameter, yang mengarah ke library mixin yang lebih kuat yang dapat menghasilkan output yang sangat ringkas. Menggunakannya untuk mixin tanpa parameter tidak begitu penting, karena saya bisa saja menggunakan fitur Less yang ada hari ini untuk menghasilkan hasil yang diinginkan.

Terima kasih semuanya untuk terus mendorong ini ke depan. Saya pikir itu bisa menjadi tambahan yang cukup kuat.

:+1 Terima kasih @matthew-dean atas perinciannya yang komprehensif - Saya setuju dengan semua yang Anda bahas. Bisakah Anda memberikan pendapat Anda tentang skenario ini, yang merupakan salah satu topik diskusi baru-baru ini:

.mixin() { color: red; }

.component {
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

Cara kerja KURANG saat ini, hanya mixin dalam lingkup global yang diperpanjang - artinya gaya merah akan diperpanjang. Saya pribadi setuju dengan perilaku ini, dan sementara seseorang cenderung menulis kode di atas dan mengharapkan gaya biru menang, saya pikir perilaku "global" dari ekstensi adalah satu baris dalam dokumentasi.

// this is ".mixin()", which is being extended
.mixin() { color: red; }

.component {
    // this is ".component .mixin()", which is not. 
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

Saya pikir perilaku ekstensi "global" adalah satu baris dalam dokumentasi.

Sangat setuju. Saya pikir itu ide yang buruk untuk memperkenalkan area abu-abu di sini.

Bagi saya, konsistensi itu penting. Jika perilaku saat ini tidak memperluas penyeleksi dalam lingkup lokal, juga tidak dengan mixin. Jika nanti kita memperluas penyeleksi di lokal, maka mixin juga harus. Orang harus bisa mempercayai pola :extend yang ada di seluruh perpustakaan.

(Meskipun saya bisa saja mengatakan dengan lebih ringkas: "+1 untuk komentar @jonschlinkert ". ;-)

Pada titik ini adakah yang bisa memberikan use case yang akan membuat fitur ini membingungkan? Silakan mulai dengan ikhtisar komprehensif ini dari @matthew-dean dan tanggapan setelahnya dan coba tawarkan situasi dunia nyata yang belum tercakup.

Selamat berlibur. Selamat Natal. Felices Fiesta!

Ikhtisar yang sangat bagus. Saya setuju dengan @matthew-dean dan setiap komentar berikut. :+1:

Saya juga setuju dengan @matthew-dean. Dia tampak seperti orang yang baik dan saya ingin menjabat tangannya.

(-Anonim)

@matthew-dean kata. :+1:

Kita bisa membuat kode sistem grid Bootstrap jauh lebih bersih dengan fitur ini!

:+1: setuju @cvrebert! akan menyenangkan!

Hanya meninjau kembali. Saya pikir kita hampir mencapai konsensus dan hanya perlu implementasi, benar?

Saya mencoba mencari info lebih lanjut tentang ini tetapi ini seperti labirin yang membaca semuanya. Apakah ini pernah diterapkan? Jika demikian, bisakah seseorang dengan ramah mengarahkan saya ke area yang sesuai di dokumen.

@josh18 Tidak, ketika permintaan fitur masih terbuka, ini biasanya berarti tidak diterapkan.

Ok terima kasih, saya pikir saya akan memeriksa ulang kalau-kalau saya melewatkan sesuatu.

Saya berencana untuk meringkas fitur yang terbuka/akan diterapkan di Wiki, tetapi belum punya waktu.

Saya berencana untuk meringkas fitur yang terbuka/akan diterapkan di Wiki, tetapi belum punya waktu.

@matthew-dean +1

Halo kawan-kawan! Sejauh yang saya mengerti fitur ini akan agak mirip dengan placeholder SASS. Hanya ingin tahu kapan ini akan diterapkan?

Hai,
Saya merasa sulit untuk memprediksi waktu saya dan kontributor lain hanya
mengimplementasikan hal-hal yang mereka minati, jadi saya tidak yakin. Yang bisa saya katakan adalah
bahwa kami menganggapnya sebagai prioritas tinggi, ini adalah hal besar berikutnya dalam daftar saya.

Terima kasih atas jawaban Anda. Looking forward untuk melihat ini diterapkan dan bekerja. :)

+1 untuk fitur ini. Ini sangat membantu dalam mengurangi ukuran CSS.

+1 untuk fitur ini.

+1 untuk fitur ini.

+1 menonton dengan penuh minat, terima kasih!

:+1:

sudah DUA TAHUN berlalu sejak masalah ini dibuat. Tag Prioritas Tinggi sejak Nov 2014. Tonggak pencapaian adalah 1.6.0 atau 2.0.0. Besar. Kurang 2,5 sekarang.

@Grawl

Maksud Anda, Anda siap membuat PR?

@seven-phases-max Itulah yang saya pikirkan. Tampilan hak seperti itu. ;)

@seven-phases-max lol tidak, saya hanya frontend/desainer.
@Celc terlihat sangat buruk

sudah DUA TAHUN berlalu sejak masalah ini dibuat.

Ya, untuk apa aku membayar kalian? ;-)

Sayangnya tidak dapat membantu dengan partisipasi, tetapi saya sangat mendukung permintaan ini!

Ini adalah fungsi yang sangat penting untuk membangun kerangka kerja yang kompleks dan efektif

3 tahun dan terus bertambah. Untungnya, Sass v4 akan datang (dengan fungsi awalan sass-* ) dan saya dapat menyingkirkan Less.

@stevenvachon Kami tidak menyimpan dendam terhadap Sass. Tentu saja mereka adalah pesaing dalam arti tertentu, tetapi proyek memiliki filosofi yang berbeda dan mencoba menyakiti kita dengan meminta mereka tidak masuk akal.

Tentu saja, permintaan tarik diterima, dari siapa pun. Kami dengan senang hati akan menggabungkan permintaan tarik fungsional dengan fitur ini.

Saya tidak mencoba menyakiti siapa pun, bahkan mungkin mencoba mencegahnya. Saya pikir lebih baik untuk mengungkapkan bagaimana perasaan seseorang dan arah baru yang mungkin mereka ambil sebagai hasilnya. Saya pikir lebih baik mengetahui lebih cepat daripada nanti; sebelum semua orang pergi. Misalnya, Bootstrap v4 tidak akan menggunakan Less.js dan saya yakin itu akan berdampak besar pada basis pengguna Anda. Anda dapat mengabaikan politik seperti itu semau Anda, tentu saja.

@stevenvachon mengapa begitu offtopic? Sass dan Less sama-sama bagus. Saya suka JS murni lebih sedikit. node-sass membutuhkan kompiler ac untuk diinstal, yang dapat menyusahkan tergantung pada lingkungan. Saya telah menggunakan fitur :extend yang sudah ada di KURANG dan memenuhi semua kebutuhan saya. Saya bahkan tidak tahu mengapa masalah ini masih terbuka.

Heck, saya seorang pengembang Rails dan menggunakan gulp+LESS ketika itu bukan proyek Ruby.

Menyimpang dari topik? Fitur ini belum diterapkan dalam 3 tahun dan akan sangat berguna.

Saya lebih suka jika Sass ditulis dalam JS, tetapi tidak, dan bukan itu yang paling penting. Fitur-fiturnya adalah. Sass memungkinkan kami untuk memperluas placeholder tetapi Less tidak memungkinkan kami untuk memperluas mixin.

Sobat itu sama sekali tidak di luar topik, tetapi fitur yang sangat dinanti! (Meskipun saya lebih suka lebih sedikit, karena berbagai alasan)

Itu hanya memohon untuk dibuat.

PS Dalam kasus saya, saya sebenarnya desainer dengan hanya beberapa pengetahuan tentang js, sebagian besar hal-hal terkait dom, sangat jauh dari pengembang yang dapat berkontribusi pada basis kode less.js..Yang merupakan cerita sedih pula)

Hanya pendukung proyek yang sangat tertarik)

Pengumuman Layanan Masyarakat

Kapan saja, Anda dapat mengirimkan permintaan tarik, atau bekerja dengan pengembang untuk mendapatkannya, dan kemungkinan besar fitur ini akan digabungkan. Pustaka Less.js membutuhkan lebih banyak kontribusi reguler dari individu seperti orang-orang di utas ini . Itu bukan tanggung jawab satu orang. Ini sepenuhnya tergantung pada satu individu yang melihat utas ini, atau membutuhkan fitur ini, dan meluangkan waktu untuk mewujudkannya.

Jika tanggapan Anda adalah bahwa Anda bukan pengembang, maka ada banyak cara LAINNYA Anda dapat mendukung proyek ini dalam peran non-pengembangan, baik itu menyediakan dokumentasi yang diperlukan untuk fitur baru, atau dukungan desain di situs web, menjalankan tes, memberikan umpan balik tentang masalah, pengelolaan proyek, menjawab pertanyaan tentang Stack Overflow, menulis posting blog, menge-tweet tentang Lebih Sedikit, berkontribusi pada CSS dan komunitas web, dan menulis Lebih sedikit perpustakaan.

Banyak dari tugas-tugas ini dilakukan oleh individu yang merupakan pengembang, sehingga waktu yang mereka berikan untuk pengembangan dihabiskan untuk tugas-tugas lain ini.

Jika Anda _adalah_ seorang pengembang, dan tanggapan Anda adalah, "Saya tidak punya waktu", maka itulah alasan yang tepat mengapa masalah ini terungkap. Ini 100% terserah Anda jika suatu fitur selesai, jadi menanyakan mengapa itu belum diselesaikan oleh "seseorang" tidak berguna. _Anda adalah seseorang itu._ Itu akan terjadi, saya _menjamin_ itu akan terjadi, jika dan ketika Anda terlibat dalam proyek ini. Anda dapat terlibat dalam salah satu alat sumber terbuka paling populer di web. Anda dapat membuat perbedaan dalam kehidupan... ribuan? Ratusan ribu? Jutaan? Dan sebagai keuntungan sampingan, Anda dapat memastikan bahwa fitur favorit Anda muncul lebih cepat daripada nanti.

Jika Anda ingin ini atau fitur apa pun terjadi, wujudkan . Kami akan senang memiliki Anda. Kami akan senang bekerja sama dengan Anda! Lebih sedikit yang bisa terus menjadi lebih baik dan lebih baik semakin besar komunitas ini tumbuh!

Dan, dengar, saya menghargai bahwa kadang-kadang orang benar-benar tidak punya waktu untuk berkontribusi namun masih sangat ingin fitur tertentu terjadi. Tidak apa-apa. Saya hanya akan mengatakan bahwa jika Anda berada dalam skenario itu, bahwa Anda bertujuan untuk empati dan rasa terima kasih kepada orang-orang yang menyumbangkan waktu mereka (dan terkadang uang) untuk membantu Anda, dan saya yakin orang lain di komunitas Less akan melakukan yang terbaik untuk terus melakukannya, karena mereka mampu.

Sungguh-sungguh,
Matthew Dean, Anggota Tim Inti Less.js

Saya sudah mendukung proyek saya sendiri dan saya mendengarkan permintaan fitur mereka. Sejujurnya saya tidak punya waktu untuk menggali inti Less.js.

Bagi mereka yang datang ke sini untuk dukungan sass placeholder (atau "kelas diam"), baca komentar ini . Itu tidak akan membawa Anda ke sana (karena #1851 dan memiliki kelas seperti itu tidak dalam file "referensi"), tetapi itu lebih baik daripada tidak sama sekali.