Less.js: Permintaan fitur: Pencarian properti (alias Properti juga Variabel)

Apa kasus penggunaan Anda? Di less.js saat ini, Anda dapat menempatkan nilai foo ke dalam variabel dan mencapai sesuatu yang serupa.

Ini:

.test {
  <strong i="7">@foo</strong>: 200;
  foo: @foo;
  bar: <strong i="8">@foo</strong> / 2;
  .child {
    baz: @foo;
  }
}

mengkompilasi menjadi:

.test {
  foo: 200;
  bar: 100;
}
.test .child {
  baz: 200;
}

Jika Anda memiliki kasus di mana refactoring seperti itu tidak memungkinkan, akan sangat membantu jika Anda mempostingnya di sini. Secara umum, less.js menambahkan fitur baru ketika beberapa kasus penggunaan tidak mungkin atau terlalu rumit untuk dilakukan. Use case akan membantu kami memutuskan berapa banyak fitur tersebut diperlukan (atau kami dapat menemukan cara lain untuk mencapai apa yang Anda inginkan).

Penggunaannya adalah Anda dapat membangun konteks semantik, misalnya:

@gutter-width: 30px;
.row {
  margin-left: -(@gutter-width / 2);
  margin-right: -(@gutter-width / 2);

  .col-half {
    width: 50%;
    float: left;
    padding-left: -$margin-left;
    padding-right: -$margin-right;
  }
}

Karena di bootstrap margin bergantung pada padding dan sebaliknya, mengapa tidak menghubungkannya secara langsung daripada hanya menggunakan variabel yang sama?

Anda akan menghapus beberapa referensi variabel dan membangun modul yang lebih koheren yang bergantung pada konteksnya daripada hanya variabel. Orang-orang dari Stylus jelas melihat usecase untuk ini jika tidak, mereka akan menganggap ini sebagai peninggalan.

Contoh lain adalah kotak peringatan:

.alert {
  color: #f00;
  background: lighten($color, 25%);
}

Saya pikir itu tidak _perlu_ tetapi _bagus untuk dimiliki_. Variabel dapat melakukan pekerjaan itu tetapi referensi properti langsung lebih mudah dibaca.

Tentu saja itu tidak perlu, sama sekali. Kami bekerja dengan variabel selama bertahun-tahun dan itu luar biasa. Terutama perilaku pemuatan malas yang tidak dimiliki oleh setiap Pra-Prosesor lainnya. Meskipun demikian saya ingin memposting ini untuk dipertimbangkan.

Saya setuju bahwa sesuatu seperti ini akan menjadi intuitif. Sering kali saya memiliki nilai awal, ditetapkan untuk properti, dan jika saya ingin menggunakan nilai itu di tempat lain, nilai itu harus difaktorkan ulang menjadi variabel dan kemudian ditambahkan kembali ke properti. Proposal ini akan lebih sederhana bagi penulis.

Ada permintaan serupa agar bagian dari pohon Less langsung dapat diakses sebagai data terstruktur, jadi saya ingin memiliki lebih banyak "pengakses" untuk apa yang telah Anda tulis.

Saya melihat kekhawatiran untuk meledakkan bahasa terlalu banyak sehingga mungkin tidak dianggap "ramping" lagi.

Terkait dengan #76 dan #6 - meskipun pendekatan ini lebih sederhana. Itu menghemat kode yang tidak berguna untuk menetapkan variabel dan kemudian membaca darinya

Membaca #76 Saya menemukan beberapa kesamaan yang mungkin digabungkan, katakanlah jika Anda background-color: lighten([color], 25%); itu akan mencari pohon leluhur saat ini. Namun jika Anda menulis background-color: lighten(#mySpecialSelector[color], 25%); itu akan menggunakan pohon ancestor dari pemilih.

Itu akan sangat berguna dan membuka tingkat peluang yang sama sekali baru.

@lukeapage Menurut Anda apa dampak kodenya? Jika properti lokal (pohon saat ini) dapat di-shimming agar berperilaku mirip dengan vars lokal, sepertinya itu bukan yang utama (tetapi Anda akan tahu lebih baik). Itu bisa menambah keanggunan tertentu pada bahasa, karena orang bisa melakukan:

.rectangle {
  width: 200px;
  height: ([width]/2);
}

Dari pada:

.rectangle {
  <strong i="10">@width</strong>: 200px;
  width: @width;
  height: (@width/2);
}

Contoh pertama tampaknya lebih mudah dibaca, dan terasa lebih dekat dengan maksud penulis. Saya pribadi telah menulis kode seperti contoh kedua berkali-kali, jadi saya suka ide ini.

Untuk pencarian lokal saja, saya pikir biayanya kecil. Menambahkan pemilih mungkin
menyebabkan lebih banyak kompleksitas parse. Bukankah kolom css menggunakan tanda kurung siku?
nilai-nilai?

Tidak, bukan kolom css, harus berpikir di mana saya melihatnya.

Nilai atribut menggunakan tanda kurung siku, jadi jika kita menyertakan pemilih dalam pencarian properti, maka tanda kurung siku tidak akan berfungsi, karena ini adalah pemilih yang valid:

#mySpecialSelector[color] {
}
// matches:
<div id="mySpecialSelector" color></div>

Tanda kurung siku cocok dengan elemen yang memiliki atribut "warna". Kita bisa lebih eksplisit, dengan sesuatu seperti prop().

.rectangle {
  width: 200px;
  height: (prop(width)/2);
}

Namun, saya tahu di masa lalu kami telah mencoba untuk menghindari tanda kurung bersarang, jadi... bagaimana jika kami menggabungkan $ dengan sintaks variabel interpolasi kami?

.rectangle {
  width: 200px;
  height: (${width}/2);
}
.example {
  background-color: lighten(${color}, 25%); 
  background-color: lighten(${color, #mySpecialSelector}, 25%);
}

Sesuatu seperti itu? Dengan begitu penyeleksi atribut valid:

.parent[id] {
  height: 50%;
  .child {
    height: (${height, .parent[id]} / 2);
  }
}

apa yang kalian pikirkan?

Saya suka ${color} .

Sebenarnya, jika kita menganggap ${} atau sintaks apa pun sebagai "referensi pohon", kita dapat mengatasi masalah seperti #1075 dengan sintaks yang sama:

.table .row .cell {
    ${.row}.editing  {}  // .table .row.editing .cell {}
}

...tapi saya tidak ingin membingungkan banyak hal. Hanya sebuah ide.

Untuk pencarian non-lokal, ini terkait langsung dengan #1848 (Saya kira bagian yang sulit hanya dalam menyusun sintaks yang konsisten, secara internal dalam variabel pohon dan properti ditangani hampir identik sehingga apa pun yang diterapkan untuk yang pertama cukup mudah diperluas untuk bekerja dengan yang kedua dan sebaliknya).

Namun jika Anda menulis background-color: lighten(#mySpecialSelector[color], 25%); itu malah akan menggunakan pohon leluhur pemilih.

Dengan cara ini #mySpecialSelector tidak dapat memiliki ancestor (karena jika memiliki maka harus direferensikan dengan *ancestor(s) #mySpecialSelector . Yaitu hanya #mySpecialSelector yang mungkin hanya cocok dengan pemilih tingkat atas di global lingkup (dan/atau opsional elemen dengan nama seperti itu di suatu tempat di atas lingkup saat ini).Tapi sekali lagi, saya pikir bagian namespacesing lebih baik untuk dibahas di #1848 (perbedaan antara variabel dan properti seharusnya hanya ada dalam sintaks (mis. selector[@variable] dan selector[property] ) _if_ yang ini diimplementasikan).

Btw., ada ide selain $ dan [] ?

Saya sedang berpikir tentang penspasian nama saat saya memikirkan ini. Secara teknis, ini berbeda karena kita (saat ini) berbicara tentang dukungan untuk referensi di pohon lokal. Kami dapat mengabaikan pencarian pemilih pada awalnya dan, seperti yang Anda katakan, memperlakukannya seperti variabel. Jika properti tidak ada secara lokal, buka blok induk berikutnya, dan seterusnya. Faktanya, kita bisa saja berpura-pura bahwa properti adalah variabel, meskipun mereka perlu direferensikan dengan cara yang berbeda. Jadi, jika kami tidak mendukung referensi namespaced vars, maka saya pikir kami awalnya tidak akan mendukung properti namespaced. Tetapi kami dapat mendukung properti yang diimpor melalui mixin, karena itu akan sama dengan apa yang dilakukan variabel. Faktanya... bukankah pada dasarnya kita sudah melakukannya, karena properti selanjutnya akan menggantikan properti sebelumnya?

Saya juga ingin merujuk vars/properti namespaced. Ini akan mengagumkan. Dan, seperti #1075, kita mungkin mendekati sintaks yang cukup fleksibel untuk menunjuk ke nilai mana pun di AST. Tapi kita tidak harus mengimplementasikannya sekaligus.

Sejauh pemilih khusus, saya tahu kami telah mencoba untuk menghindari memperkenalkan simbol tambahan dalam masalah ini, tetapi saya merasa seperti kami telah melompati rintangan di #1075 dan #1848 untuk tidak melakukannya. Misalnya, di #1848, di akhir saya sebutkan sintaks ini:

.box:after {
  content: "@{#ns > @content}";
}

Tapi, tentu saja, tambahan @ di awal hanya masuk akal jika saya merujuk variabel namespace. Namun, itu tidak diterjemahkan secara semantik ke referensi properti, sementara simbol tambahan yang merupakan "pencarian" lebih fleksibel:

// property
.box:after {
  content: "${#ns > content}";
}
// or a variable
.box:after {
  content: "${#ns > @content}";
}

Jadi, mungkin kita bisa membunuh dua (mungkin 3) burung dengan satu batu dan memecah tugas seperti ini:

• Langkah 1: Mendukung properti sebagai "vars" (dengan kemungkinan pengecualian)
• Langkah 2: Alamat contoh kedua @krnlde hanya dengan mendukung referensi namespace daripada pemilih "lokal": ${#mySpecialSelector > color}

Sejauh alternatif untuk $ , saya pikir kita harus dibatasi pada tombol shift dan baris angka. Kami tidak dapat menggunakan ! , @ , # , & , * , ~ , `` , as it either conflicts with CSS or Less. That leaves $ , % , ^ . I suppose there's a few more symbols on the keyboard, but if we're going to add one, $` akan menjadi pilihan pertama saya.

Bagaimana dengan § , / dan \ ?

\ digunakan untuk karakter Unicode. Sisanya harus baik-baik saja. Apakah § mudah diakses di keyboard bahasa Inggris? Saya tidak punya satu untuk memverifikasi atm.

Apakah § mudah diakses di keyboard bahasa Inggris? Saya tidak punya satu untuk memverifikasi atm.

Eh, tidak. Tidak tahu apa itu.

Ini adalah tanda paragraf dalam hukum (Jerman)

Ah, benar, saya pikir saya pernah melihatnya. Bagaimanapun, itu tidak ada di keyboard.

Baik. Seperti yang saya ketahui dengan mengutak-atik, / tidak hanya rumit tetapi juga tidak dapat digunakan karena ini adalah operator pembagian yang lebih sedikit, jadi padding-top: /height//line-height; tidak akan berfungsi. Jadi saya kira kita tetap dengan $ untuk saat ini? Seperti padding-top: $height/$line-height; . Terlihat bagus

Doh, saya khawatir saya akan memilih $ juga karena tampaknya paling bersih dan paling tidak bertentangan (walaupun jujur ​​saya sangat membencinya (tanpa alasan tertentu) dan karena itu saya merasa sakit setiap saat Saya harus menulis sesuatu dalam PHP :)

@seven-phases-max - Haha, saya memiliki reaksi mendalam yang sama saat pertama kali diangkat, untuk alasan yang sama. Namun, saya menjadi lebih pragmatis akhir-akhir ini, dan mengubah simbol yang ada menjadi lebih berarti (seperti yang telah kami mainkan sehubungan dengan @ dan & ) untuk menghindari penambahan yang baru , atau untuk membatasi diri kita pada kumpulan simbol CSS mungkin merupakan senam yang tidak perlu, dan belum tentu merupakan solusi yang paling mudah dipahami. Saya pikir lebih mudah bagi pengguna untuk memahami simbol jika mereka memiliki perilaku yang lebih berbeda. Dan CSS tidak memiliki perilaku tertentu yang kami wakili, jadi dalam beberapa kasus mungkin tidak bijaksana untuk mengkooptasi / menggunakan kembali simbol CSS. Itu mungkin banyak bertentangan dengan apa yang saya katakan di masa lalu, tetapi seperti yang saya katakan, saya tidak yakin ketegasan seperti itu selalu diperlukan.

Dan juga, relatif terhadap poin Anda, jika kami memperluas definisi simbol yang ada, kami dapat mundur ke sudut jika kami ingin memperluas penggunaan lebih lanjut.

Yang mengatakan, _karena_ ini mungkin simbol / metode referensi baru, saya pikir itu layak mendapatkan banyak masukan / konsensus untuk itu.

Saya mengerti bahwa mampu melakukan ini:

.rectangle {
  width: 200px;
  height: ${width} / 2;
}

bisa bagus tapi ini:

.example {
 color: lighten(${color, #mySpecialSelector}, 25%);
}

tidak berguna rumit untuk dibaca dan dikelola. Jika seseorang memberi saya sepotong kode seperti ini untuk dikerjakan, itu akan sangat membosankan dan rumit untuk mengetahui mana yang merupakan warna sebenarnya lighten .
Bagi saya jika terasa kurang lebih seperti dalam pengaturan javascript properti dari simpul DOM dengan cara ini:

var el1 = document.createElement('div');
var el2 = document.createElement('div');
el1.className = document.querySelector('mySpecialSelector').id + '25percent';
el1.className = document.querySelector('mySpecialSelector').id + '10percent';

dari pada:

var CLASS_NAME = 'my-color-class';
var el1 = document.createElement('div');
var el2 = document.createElement('div');
el1.className = CLASS_NAME + '25percent';
el1.className = CLASS_NAME + '10percent';

Saya tidak tahu apakah saya memberikan ide tentang apa yang saya maksud. Tapi saya pikir semua ini aneh, setidaknya bagi saya dan saya tidak akan menggunakannya. Secara keseluruhan saya pikir variabel adalah abstraksi yang baik dan solid yang sudah mencakup semua kasus ini. Membuat bahasa lebih kompleks tidak membuatnya lebih kuat. Dan membuatnya kurang terbaca juga tidak membantu.
my2c

ini:

.example {
 color: lighten(${color, #mySpecialSelector}, 25%);
}

tidak berguna rumit untuk dibaca dan dikelola.

Saya setuju. Itu sebabnya saya pikir bagian itu mungkin layak untuk dipindahkan ke utas referensi namespace (#1848), seperti yang disarankan @seven-phases-max, dan tetap merujuk dalam format namespace. Untuk utas khusus ini, satu-satunya hal di atas tabel harus merujuk pada nilai properti.

@kuus , @matthew-dean menyetujui itu. Mungkin terlalu banyak.

Bagaimana dengan mixin? Haruskah mereka mencari orang tua terdekat _mereka_ atau pohon tempat mereka akan ditempatkan? Tidak dapat memberikan contoh atm, saya menggunakan ponsel - akan memberikannya nanti jika perlu.

@kuus Mixins mencari variabel di induknya sendiri terlebih dahulu. Jika pencarian tidak ditemukan, pencarian berlanjut di tempat penempatannya. Saya pikir properti harus bekerja dengan cara yang sama: pencarian definisi mixin pertama dan pemanggil kedua.

:+1:

Jadi untuk meringkas keadaan diskusi saat ini:

• Kami setuju untuk menggunakan sintaks interpolasi $-sign: ${width} meskipun $width akan lebih pendek dan yang pertama tidak memiliki keuntungan (mungkin perlu diskusi lebih lanjut saat kami melanjutkan).
• Kami hanya membiarkan properti mencari cakupan saat ini ke atas. Selector seperti berikut tidak diperbolehkan : height: ${width, .my-selector} atau height: .my-selector${width} .
• Kami setuju bahwa referensi properti di mixin akan mencari pohon mixin terlebih dahulu dan kemudian - jika tidak berhasil - pohon tempat mereka ditempatkan.

Bagaimana dengan "pemuatan malas" tercinta dari Variabel-kurang? Apa pengaruh pengetahuan ini terhadap properti?

@krnlde

Saat ini saya akan membatasi daftar hanya untuk: $width - mengacu pada properti width yang mencari dari lingkup saat ini ke atas.

(Namespacing dan sintaks ${...} perlu diskusi lebih lanjut).

Saat ini saya akan membatasi daftar hanya untuk: $width - mengacu pada pencarian properti lebar dari cakupan saat ini ke atas.

Sepakat. Saya mendukung melakukan kedua sintaks, jadi logis untuk memulai dengan variasi yang lebih "terbatas", dan menyelesaikan ${} setelah itu.

Kebetulan @krnlde , saya sekarang mendukung versi namespaced _bukan_ pencarian pemilih "dalam pohon", karena itu tampaknya lebih fleksibel, tetapi mari kita mulai dengan $property dan mulai dari sana.

Sejauh ini bagus. Bagaimana kita melanjutkan?

Yah, sepertinya kita memiliki cukup dukungan dari para kontributor, jadi saya rasa kita bisa menandainya sebagai siap untuk diterapkan, kecuali jika ada keberatan yang memaksa.

Pada 5 Februari 2015, pukul 12:20, Kai Dorschner [email protected] menulis:

Sejauh ini bagus. Bagaimana kita melanjutkan?

—
Balas email ini secara langsung atau lihat di GitHub.

Mengapa & tidak tersedia? AFAIK, Less tidak menggunakan & kecuali dalam penyeleksi. Dan plus, saya pikir & lebih baik untuk referensi.

AFAIK, Less tidak menggunakan & kecuali di penyeleksi.

Ya sekarang. Tetapi kita tidak boleh mencuri simbol dari fitur lain yang mungkin (walaupun terlalu jauh).

Saat ini, & adalah operator gabungan untuk pemilih dan tidak digunakan untuk pencarian apa pun. Masalah ini adalah tentang referensi properti dan memperlakukannya seperti referensi variabel, jadi seperti yang ada sekarang, konsepnya cukup berjauhan.

& digunakan sebagai referensi dalam beberapa bahasa pemrograman seperti C++. Saya lebih setuju pada poin Max bahwa kita dapat menggunakannya seperti yang dilakukan Sass sekarang di masa depan:

.foo.bar .baz.bang, .bip.qux {
  $selector: &;
}

@seven-phases-max Saya pikir kita harus membuatnya mencari ruang lingkup mixin terlebih dahulu dari awal. Bahasa lebih mudah dipelajari dan dibaca jika berperilaku secara konsisten. Lebih sedikit pelingkupan memiliki terlalu banyak aturan untuk diingat (imo), menambahkan satu ad hoc baru tidak akan membuatnya lebih mudah.

Lebih mudah untuk mengatakan "ada pelingkupan dan pelingkupan berfungsi seperti ini" kemudian memiliki pelingkupan yang sedikit berbeda untuk setiap fitur (set aturan terpisah, properti, variabel, pencarian mixin). Mengubah pelingkupan nanti lebih sulit daripada membuatnya sama seperti yang sudah ada sejak awal.

Saya berpikir bahwa ini:

#namespace() {
   padding-right: 2;
  .miniPadding() {
     padding-left: $padding-right - 1;
  }
}

.big-table {
   padding-right: 5;
  .sub-table {
    #namespace() > .miniPadding();
  }
}

harus dikompilasi ke:

.big-table {
   padding-right: 5;
}
.big-table .sub-table {
   padding-left: 1;
}

kompilasi untuk mengikuti hanya akan membingungkan/tidak terduga dan terlihat seperti bug:

.big-table {
   padding-right: 5;
}
.big-table .sub-table {
   padding-left: 4;
}

Plus, jika variabel dan pelingkupan properti berperilaku dengan cara yang sama, maka kita mungkin dapat menggunakan struktur dan kode yang persis sama untuk menanganinya - dan sebagian besar bug di salah satunya akan diperbaiki di yang lain juga. Dua pelingkupan berbeda (atau tiga ketika Anda menghitung dalam perbedaan aturan yang terpisah) berarti mempertahankan dua algoritma yang serupa tetapi agak berbeda yang lebih sulit.

Anda menggambarkan perilaku penutupan yang normal. Masuk akal bagi saya.

@SomMeri

Saya pikir kita harus membuatnya mencari ruang lingkup mixin terlebih dahulu dari awal.

Tapi saya menulis persis sama :) ( Upd:. Err, maksud saya "maksud saya aturan pencarian properti harus persis sama dengan variabel", (lebih dari itu saya tahu mereka sudah _are_ sama di dalam kompiler karena ini adalah kode yang sama yang menangani variabel dan properti (dengan beberapa minor if s)).

mencari dari lingkup saat ini ke atas.

adalah kutipan tepat dari Variables > Lazy-Loading .

Berbicara tentang contoh Anda, itu sangat tidak menyenangkan. Karena contoh yang sama dengan variabel masuk ke #1316 dan hasilnya adalah padding-left: 4; . Saya mengerti mengapa Anda menggunakan #namespace() di sana tetapi dengan semua masalah "ruang nama parametrik" itu bisa sangat membingungkan. Kami memerlukan beberapa contoh lain (karena contoh Anda persis di tempat yang lebih baik menggunakan variabel daripada properti).

PS Anehnya: selama tiga hari terakhir empat isu yang berhubungan langsung dengan #1316 muncul (#2435, #2350, #2436 dan sekarang contoh Anda) Apakah ini semacam konspirasi? :)

@seven-phases-max Saya salah paham dan lupa tentang #1316. Maaf tentang keduanya :).

Keempat masalah itu adalah masalah mendasar yang sama? Apakah mudah/sulit untuk memperbaikinya menurut Anda? Saya belum ingin melakukan perubahan besar dalam less.js (tahu terlalu sedikit tentang cakupannya), tetapi saya mencari sesuatu yang mudah hingga sedang sulit untuk diperbaiki.

Apakah saya satu-satunya yang berpikir bahwa semua ini tidak perlu dan membuat bahasa menjadi lebih rumit dan kurang mudah dibaca? Apa manfaat sebenarnya yang Anda cari?
Ketika saya membaca deklarasi gaya, saya tidak ingin menjadi gila untuk memahami dari mana nilai properti itu berasal. Seperti sekarang itu harus berupa nilai normal atau variabel, atau maksimum perhitungan sebaris yang menggunakan variabel. Itu dia. Ini membuat praprosesor css menyenangkan untuk digunakan. Apa yang Anda usulkan adalah semacam cara dinamis untuk mendefinisikan variabel, yang aneh. Saya tidak bagaimana pengembang javascript tidak bisa setuju dengan fakta yang aneh.

Pasti saya setuju dengan @SomMeri ketika dia mengatakan

Lebih sedikit pelingkupan memiliki terlalu banyak aturan untuk diingat (imo) sudah"

Dan saya pikir kode sampelnya https://github.com/less/less.js/issues/2433#issuecomment -73202522 tidak peduli apa yang dikompilasi, itu terlalu berbelit-belit.

Definisi dari Stylus :

Pencarian Properti

Fitur keren lainnya yang unik untuk Stylus adalah kemampuan untuk mereferensikan properti yang ditentukan tanpa menetapkan nilainya ke variabel. Contoh yang bagus dari hal ini adalah logika yang diperlukan untuk memusatkan elemen secara vertikal dan horizontal (biasanya dilakukan menggunakan persentase dan margin negatif, sebagai berikut): ...

Jadi untuk menangkap usecase yang saya jelaskan sebelumnya, Anda dapat mempersingkat definisi dengan menyimpan variabel, ditambah lagi lebih ringkas karena Anda menghubungkan properti secara langsung daripada melalui variabel:

.mySquare {
  width: 200px;
  height: $width;
}
.myRectangle {
  width: 500px;
  height: $width / 2;
}

Hanya dengan membaca height: $width; semua orang tahu persis apa yang terjadi di sana - itu adalah persegi, tidak peduli apa.

Diskusi bersarang dan apakah harus mencari semua pemilih induk harus didiskusikan di tempat lain (#1848).

@kuus

Yah, keterlibatan saya hanya terbatas pada berkeliaran dan berteriak jika beberapa sintaks/perilaku yang diusulkan keluar dari kendali :) Sebenarnya saya tidak mendukung atau menentangnya (saya tidak akan keberatan karena itu terbang dari awal Kurang hari (bahkan (sebagian?) diimplementasikan dalam versi Ruby awal) dan saya tahu itu seharusnya tidak membebani kompiler kecuali kita mulai menciptakan konstruksi sintaksis yang gila ... Saya juga tahu bahwa fakta bahwa suatu fitur mendapatkan "ReadyForImplementation" tidak berarti itu benar-benar akan diimplementasikan segera atau selamanya ... ;)

@SomMeri

Keempat masalah itu adalah masalah mendasar yang sama? Apakah mudah/sulit untuk memperbaikinya menurut Anda?

Ya, ini adalah masalah mendasar yang sama tetapi dalam banyak kasus ini lebih tentang harapan yang berbeda tentang bagaimana hal-hal ini seharusnya bekerja (tentang bagaimana pelingkupan harus bekerja dan bagaimana cara kerjanya sebenarnya) dan bukan kode yang menderita #1316 . Kami membahas kemungkinan cara untuk memperbaiki #1316 sendiri di sekitar https://github.com/less/less.js/issues/2212#issuecomment -57281241 (tidak begitu mudah tetapi mungkin mungkin) tetapi masalah tersebut (half-issues/half-feature -requests) yang saya sebutkan (kecuali contoh Anda di atas tentu saja) sebenarnya meminta untuk memperbaikinya dengan cara yang berlawanan atau memberikan pintu belakang untuk itu (sehingga melanggar perilaku Less saat ini, contoh yang baik adalah #2435).

@krnlde saya minta maaf karena salah menyebutkan ...

Ketika saya membaca deklarasi gaya, saya tidak ingin menjadi gila untuk memahami dari mana nilai properti itu berasal. Seperti sekarang itu harus berupa nilai normal atau variabel, atau maksimum perhitungan sebaris yang menggunakan variabel. Itu dia. Ini membuat praprosesor css menyenangkan untuk digunakan. Apa yang Anda usulkan adalah semacam cara dinamis untuk mendefinisikan variabel, yang aneh. Saya tidak bagaimana pengembang javascript tidak bisa setuju dengan fakta yang aneh.

Saya pikir Anda mungkin salah paham. Tidak ada yang diusulkan di sini yang merupakan cara dinamis untuk mendefinisikan variabel. Ini sebenarnya tampak seperti langkah yang sangat intuitif karena beberapa alasan.

Variabel di Less datang langsung dari (atau terinspirasi oleh) perilaku properti. Di beberapa praprosesor, jika Anda menetapkan variabel, lalu membacanya, lalu menetapkannya, lalu membacanya, semua dalam lingkup yang sama, Anda akan mendapatkan hasil yang berbeda. Di Kurang, perilakunya seperti properti CSS: deklarasi terbaru dalam cakupan menang. Jadi, saat ini, variabel dan properti memiliki banyak tumpang tindih. Jika Anda memanggil mixin, Anda tidak hanya mendapatkan propertinya tetapi juga variabelnya. Dan Anda sebenarnya dapat melakukan hal-hal seperti menambahkan properti bersama-sama (atau lebih tepatnya, menambahkan nilainya) dengan sintaks property+: dan property+_: . Satu hal yang tidak dapat Anda _yet_ lakukan adalah mereferensikan properti.

Jadi, variabel dimaksudkan untuk berperilaku seperti properti, dan properti telah berevolusi untuk berperilaku seperti variabel. Pada akhirnya, Anda menetapkan nilai ke kunci. Kami memiliki cara untuk mereferensikan nilai untuk satu jenis kunci, dan apa yang diusulkan di sini hanyalah cara untuk mereferensikan nilai untuk jenis kunci lainnya.

Lebih sedikit pelingkupan memiliki terlalu banyak aturan untuk diingat (imo) sudah

Tidak akan ada aturan pelingkupan tambahan yang perlu diingat. Kedua blok ini akan menjadi setara secara fungsional sejauh pelingkupan.

.block {
  <strong i="15">@height</strong>: 10px;
  width: <strong i="16">@height</strong> / 2;
}
.block {
  height: 10px;
  width: $height / 2;
}

Perbedaannya adalah bahwa tinggi adalah output sebagai properti di blok kedua. Tapi cakupannya tidak berubah.

Atau cara TL;DR untuk mengatakannya: properti di Kurang, pada umumnya, sudah bertindak seperti variabel, tetapi Anda tidak dapat merujuknya. Fitur ini akan memungkinkan referensi properti.

Cara lain untuk menunjukkan hal di atas:

//Less
.block {
  <strong i="7">@height</strong>: 10px;
  width: <strong i="8">@height</strong> / 2;
  <strong i="9">@height</strong>: 20px;
}
// output
.block {
  width: 10px;
}
//Less w/ property reference
.block {
  height: 10px;
  width: $height / 2;
  height: 20px;
}
//output
.block {
  width: 10px;
  height: 20px;
}

Contoh @krnlde mengilhami demo lain:

.square(@width) {
  height: @width;
}
<strong i="7">@row</strong>: 100px;
.column-2 {
  width: <strong i="8">@row</strong> / 2;
  .square($width);
}
.column-4 {
  width: <strong i="9">@row</strong> / 4;
  .square($width);
}


// output
.column-2 {
  width: 50px;
  height: 50px;
}
.column-4 {
  width: 25px;
  height: 25px;
}

Ini adalah fitur yang berguna, dalam kasus saya, saya hanya perlu memperluas beberapa properti tertentu dari kelas lain (kelas itu didefinisikan dalam stylesheet eksternal sehingga untuk menggunakan variabel saya harus memodifikasi stylesheet itu di setiap versi baru yang mereka terbitkan)

Dengan sintaks baru ini saya bisa melakukannya seperti ini:

stylesheet.less disediakan dari sumber lain:

.divheader{
   height:50px;
   color: red;
   line-height: 1.5;
   width: 100px;
}

stylesheet saya.less:

.mydivheader{
   .divheader.height; //invented syntax
   .divheader.line-height; //invented syntax
   color: black;
}
//output
.mydivheader{
   height:50px; //inherited
   line-height: 1.5; //inherited
   color: black;
}

Jadi saya hanya mewarisi properti tinggi dan tinggi garis dari kelas divheader ...

@ase69s Dalam kasus Anda, kami perlu menangani variabel referensi dalam set aturan. Lihat #1848. Pada dasarnya, fitur ini akan membuat penugasan properti berperilaku (agak) seperti penugasan variabel (walaupun dengan sintaks referensi yang berbeda), sehingga kasus Anda tidak akan terjadi sebelum #1848 ditangani.

Jika / ketika diimplementasikan, saya akan melihat sintaksnya sedikit lebih dekat dengan ini:

.divheader{
   height: 50px;
   color: red;
   line-height: 1.5;
   width: 100px;
}
.mydivheader {
  height: ${.divheader > height};
  line-height: ${.divheader > line-height};
  color: black;
}

Namun, karena Anda tidak menghitung apa pun, ada beberapa opsi lain yang tersedia untuk Anda saat ini, seperti:

<strong i="11">@divheader</strong>: {
  height: 50px;
  line-height: 1.5;
};
.divheader{
  @divheader();
   color: red;
   width: 100px;
}
.mydivheader {
  @divheader();
  color: black;
}

Anda juga dapat memiliki mixin yang menyetel properti, atau menggunakan :extend pada set aturan umum. Jadi daripada secara langsung mereferensikan kelas lain, Anda dapat meminta dua div mereferensikan kumpulan aturan atau mixin terpisah lainnya.

+1 Saya sepenuhnya setuju dengan Justineo :
"_Saya pikir itu tidak perlu tetapi bagus untuk dimiliki. Variabel dapat melakukan pekerjaan tetapi referensi properti langsung lebih mudah dibaca._"

Saya akan mengatakan ini lebih dari menyenangkan untuk dimiliki. Saya memiliki situs yang memungkinkan Anda membuat skin dengan memilih warna trim yang mengontrol tombol, tautan, dan elemen lain-lain. Ini disimpan dalam database, dan di-bootstrap ke halaman melalui tag <style> di header sebagai kelas "trim". Tetapi karena nilai ini dikodekan dengan keras, saya tidak memiliki cara mudah untuk merujuknya untuk melakukan hal-hal seperti membuat versi pudar dengan warna yang sama sesuai permintaan, dan saya lebih suka tidak menggunakan JS untuk penataan...

Seperti yang ada sekarang, saya harus secara manual memilih varian off-shade dari warna trim dan menetapkannya ke kelas juga, tetapi meskipun demikian, saya tidak memiliki kontrol yang sangat mudah atas properti MANA yang warna trim pudar akan diterapkan ke (misalnya perbatasan), latar belakang dalam, dll.

@jlem Sudah ada PR yang sedang berjalan (yang saya kerjakan - https://github.com/less/less.js/pull/2654), dan pada dasarnya berfungsi, tetapi ada beberapa masalah kecil yang harus diselesaikan. Kasus penggunaan yang menarik, tetapi itu tidak akan berlaku di sini, karena gaya lain tidak akan dapat diakses oleh Less.

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

Perhatikan bahwa referensi properti sederhana ( $prop ) diimplementasikan, tetapi tidak didokumentasikan (AFAIK).