Less.js: Less gagal untuk mengurai nilai Properti Kustom yang valid (mis .: @apply polyfill)

Saya khawatir dukungan sintaks non-CSS berada di luar lingkup Less. Jadi saya -1.

Perhatikan bahwa Anda dapat memancarkan kode apa pun ke dalam output dengan escaping. Misalnya:

xpaper-drawer-panel {
  --paper-drawer-panel-left-drawer: ~"{background-color: red;}";
}

Atau dengan cara multiline yang lebih hackish:

paper-drawer-panel {
  -:~";--paper-drawer-panel-left-drawer: {";
    background-color: red;
    color: blue;
  -:~";}";
}

Dalam situasi yang lebih kompleks, selalu memungkinkan untuk menggunakan <strong i="13">@import</strong> (inline) .

Sedangkan untuk percobaan seperti %(~"%d", @ruleset); - Tidak, Variabel yang lebih sedikit bukanlah makro, variabel tersebut tidak diperluas terlepas dari konteksnya, dan khusus untuk kumpulan aturan yang tidak bernama, satu-satunya sintaks yang tepat adalah @ruleset() dalam badan kumpulan aturan dan _not_ as nilai properti.

Saya setuju dengan Anda bahwa sintaks non-standar umumnya tidak didukung.

Namun ini berarti LESS tidak kompatibel dengan Polymer dalam banyak kasus.

Terima kasih atas balasannya. : +1:

Tidak yakin apakah ini membuat perbedaan dalam keputusan Anda @ seven-phases-max tetapi ada spesifikasi terbuka untuk aturan @apply , http://tabatkins.github.io/specs/css-apply-rule/ #issue -882293bd.

Lihat juga https://github.com/Polymer/polymer/issues/1373 karena sepertinya Google benar-benar akan mendorong proses tersebut.

Dan SASS tampaknya menangani https://github.com/sass/sass/issues/1128 ini

@ donny-dont Catatan Saya tidak memutuskan apa pun (saya tidak menutup proposal) - Saya hanya seorang kritikus.

Nah, Tab Atkins menghasilkan _tens_ proposal standar CSS (bernama "ide") dan sementara orang Google mungkin mendorong ini ke browser mereka bahkan besok, ini masih terlalu jauh dari menjadi bahkan hal draf CSS (ingat CSS vars tidak memasuki dunia CSS selama sekitar sepuluh tahun?).

@ seven-phases-max mohon maaf atas implikasinya. Saya hanya ingin membuat catatan bahwa Polymer mendorong proposal mixin dan Chrome kemungkinan akan menerapkannya setelah dibentuk yang merupakan sesuatu yang tidak benar-benar dikomunikasikan oleh @Jamtis .

Saya cukup baru menggunakan LESS, apakah ada sistem plugin untuk parser dalam skenario semacam ini? Sesuatu seperti bendera eksperimental yang dapat Anda aktifkan dan nonaktifkan?

Saya membuka kembali ini untuk dapat mengarahkan permintaan duplikat di sini.

/sub

Kami memiliki spesifikasi untuk ini; ada polyfill; Chrome telah menerapkannya; Polymer sudah menggunakannya dalam rilis 1.0; dan situs web sudah menggunakan Polymer.

Saya pikir itu adalah harapan yang sangat masuk akal bagi Less untuk mendukung sintaks pada tingkat minimal.

Lebih sedikit yang sudah melewati @apply , --foo: bar; , dan var(--foo) melalui. Satu-satunya hal yang hilang adalah membuat Less melewati { ... } dalam --foo: { property: value; } dengan pemrosesan dasar yang sama yang diberikan ke blok css lainnya; alih-alih berhenti keras dan melakukan kesalahan penguraian.

Saya pikir spesifikasi lengkap Variabel CSS harus didukung oleh LESS. Akan sangat senang jika ini terjadi!

@santrikece

Kami memiliki spesifikasi untuk ini; ada polyfill; Chrome telah menerapkannya; Polymer sudah menggunakannya dalam rilis 1.0; dan situs web sudah menggunakan Polymer.

Bagi saya, itu masih bukan alasan yang kuat. Artinya: Google, Google, dan Google menggunakan ini. Tidak ada minat yang muncul di tempat lain, dan tidak ada indikasi akan ada.

@ donny-jangan

Saya cukup baru menggunakan LESS, apakah ada sistem plugin untuk parser dalam skenario semacam ini? Sesuatu seperti bendera eksperimental yang dapat Anda aktifkan dan nonaktifkan?

Ada sistem plugin, tetapi tidak ada dukungan langsung untuk mengubah penguraian. Jadi, itu bukanlah hal yang sepele untuk dilakukan.

@santrikece
Kami memiliki spesifikasi untuk ini; ada polyfill; Chrome telah menerapkannya; Polymer sudah menggunakannya dalam rilis 1.0; dan situs web sudah menggunakan Polymer.

Bagi saya, itu masih bukan alasan yang kuat. Artinya: Google, Google, dan Google menggunakan ini. Tidak ada minat yang muncul di tempat lain, dan tidak ada indikasi akan ada.

Kesimpulan itu akan masuk akal jika kita berbicara tentang sintaks yang lebih berpemilik dan tidak didukung yang menyimpang secara signifikan dari css normal; tetapi kita berbicara tentang Kurang menghasilkan kesalahan parse ketika Less sudah memahami penumpukan dan sintaks yang dimaksud sangat cocok dengan aturan parse berdasarkan pencocokan braket CSS dan tidak merusak css di sekitarnya, dan preprosesor dan postprosesor CSS utama lainnya sedang mengerjakan mendukungnya atau sudah bekerja.

Kesimpulan itu akan masuk akal jika kita berbicara tentang sintaks yang lebih berpemilik dan tidak didukung yang menyimpang secara signifikan dari css normal; tetapi kita berbicara tentang Kurang menghasilkan kesalahan parse ketika Less sudah memahami penumpukan dan sintaks yang dimaksud sangat cocok dengan aturan parse berdasarkan pencocokan braket CSS dan tidak merusak css di sekitarnya, dan preprosesor dan postprosesor CSS utama lainnya sedang mengerjakan mendukungnya atau sudah bekerja.

Tidak relevan. Ini sangat mirip dengan seperangkat aturan yang terlepas dari Less. Dan ada preseden untuk item "pass-thru" lainnya yang ditambahkan ke Less. Jadi saya tidak selalu menentangnya. Hanya skeptis jika ada nilai di luar Polymer saat ini.

Dukungan Resmi untuk Variabel CSS tercantum di sini: http://caniuse.com/#feat = css-variable

Versi Browser Minimum untuk Dukungan Variabel CSS default

• Chrome 49
• Chrome untuk Android 51
• Browser Android 51
• Firefox untuk Android 47
• Firefox 31
• Safari 9.1
• iOS Safari 9.3
• Opera 36
• Opera Mobile 37

Tanpa polyfill, ini setara dengan sekitar 65% penggunaan browser global.

Dengan beberapa CSS Variable Polyfills di luar sana, browser menerapkannya dan penyedia browser besar mendorongnya. Sepertinya ini akan menjadi fitur yang berharga untuk dimiliki.

Spesifikasi Resmi: https://drafts.csswg.org/css-variables/

@stramel Itu tidak ada hubungannya dengan masalah ini. Variabel CSS sudah didukung di Less. Permintaannya sekitar @apply , yang bukan bagian dari spesifikasi itu.

EDIT: tidak semua nilai Properti Kustom CSS didukung, lihat di bawah.

@ matthew-dean Maaf, saya salah paham. Terlepas dari,: +1: untuk Campuran CSS / Kumpulan Properti Khusus

@ matthew-dean apa bar untuk kurang mendukung? Jika browser lain diimplementasikan, bagus untuk melanjutkan?

@ donny-dont Karena Less adalah proyek komunitas, tidak ada batasan khusus. Tapi ya, sesuatu di luar satu browser akan menjadikannya fitur yang lebih umum.

Hanya jika seseorang mencari ini (seperti yang saya lakukan): Anda dapat meletakkan semua Polymer css non-standar dalam file terpisah dan mengimpor ini dengan kata kunci inline di file less Anda. File yang lebih sedikit harus memiliki antarmuka antara lebih sedikit variabel dan properti kustom polimer. Tapi begitulah yang diinginkan Polymer. Setuju Anda tidak dapat menerapkan setiap penyimpangan dari standar.

Sekadar meninjau kembali ini, saya rasa sayangnya saya memiliki pandangan sempit tentang ruang lingkup masalah.

Yaitu: ya, @apply hanyalah sebuah proposal, TAPI REGARDLESS, _this_ is _not_ invalid CSS. Tidak lagi.

paper-drawer-panel {
  --paper-drawer-panel-left-drawer: {
    background-color: red;
  };
}

Kesalahan saya adalah berpikir bahwa @apply mengusulkan ekstensi ke sintaks Properti Kustom, tetapi ternyata tidak. _IS_ di atas nilai properti khusus yang valid, dan, oleh karena itu, harus ditambahkan ke Dukungan Less. Saya berharap saya telah meluangkan waktu untuk menggali lebih dalam tentang spesifikasi. (Di sini: https://www.w3.org/TR/css-variables/#syntax.)

Less memiliki tujuan inti untuk mendukung CSS yang valid, dan sintaksis Properti Khusus diterapkan sepenuhnya di setiap browser mulai sekarang. Spesifikasi ini sangat permisif, dan mungkin memerlukan beberapa perubahan besar dalam cara penguraian nilai properti. Anda bisa memasukkan hampir semua hal ke dalamnya. Betapa gilanya Anda dengan nilai-nilai dan apakah browser akan mengizinkannya, saya tidak yakin. Tapi, cara saya membaca spesifikasi, kebanyakan semuanya valid jika dibentuk dengan baik. Artinya, sampai Anda menemukan tanda titik koma "tingkat atas", Anda bisa menjadi gila, membungkus segala macam hal dengan tanda kurung atau kurung kurawal.

Ini berarti bahwa pustaka JavaScript seperti Polymer semakin cenderung "meretas" CSS untuk menempatkan properti / nilai deklaratif di tempat yang dapat dibaca oleh JS, yang sebenarnya tidak mungkin dilakukan sebelum fitur CSS ini.

Jadi 👍 untuk menerapkan ASAP.

Maaf bagi mereka yang mencoba menunjukkan bahwa ini adalah sintaks properti kustom yang valid.

Terkait: https://github.com/less/less.js/issues/2986

Saya menandai ini sebagai bug dan permintaan fitur karena a) Lebih sedikit klaim untuk mengurai nilai properti khusus, tetapi terkadang gagal (tetapi tidak jelas kapan), tetapi b) jenis nilai yang Kurang perlu ditangani berada di luar desain asli bahkan CSS itu sendiri, apalagi Less, jadi ini adalah fitur baru.

Tes lain yang bisa ditambahkan ke tes Less untuk penguraian properti kustom. Ini adalah CSS yang benar-benar valid untuk hari ini.

.test {
  --custom-function: () => { let x = 1; window['NAMESPACE'].doSomething(x); };
}

Pada dasarnya, setelah ada sesuatu di () [] atau {} , Anda dapat memasukkan karakter apa pun yang Anda inginkan. Jadi, titik koma akan lewat pada contoh di atas. Ini membutuhkan beberapa penguraian rekursif sampai kawat gigi cocok dan ditutup (jika / saat dibuka) sebelum Anda dapat menguji titik koma penutup.

Saya memulai pekerjaan itu di sini tetapi belum yakin apakah ini benar. https://github.com/less/less.js/blob/edge/lib/less/parser/parser.js#L1326

_Catatan: untuk memperjelas jika ada yang bingung melihat baris di atas, JavaScript ini tidak akan MELAKUKAN apa pun. CSS hanya akan menganggapnya sebagai nilai anonim yang panjang dan tidak diketahui._

Pada dasarnya, setelah ada sesuatu di () [] atau {}, Anda bisa membuang karakter apa pun yang Anda inginkan.

mm, apakah itu? Bagi saya https://www.w3.org/TR/css-variables/#syntax terdengar seperti token apa pun (kecuali yang tercantum di sana) dapat berada di mana saja di sana (terlepas dari kedua jenis paren). Atau apakah ini diasumsikan oleh paragraf lain? Bisakah Anda, tolong tunjukkan, di mana dikatakan tentang karakter apa pun , atau sesuatu yang spesifik tentang nilai di dalam orang tua ? (kecuali tentu saja url(...) )?

Dengan kata lain, apakah --var: ?; , --var: (?); atau --var: [¾]; benar-benar valid?

Ini adalah bagian yang relevan di atas, yang mungkin saya salah tafsirkan.

Sintaks yang diizinkan untuk properti kustom sangat permisif. Produksi <declaration-value> cocok dengan urutan apa pun dari satu atau lebih token, selama urutan tersebut tidak mengandung <bad-string-token> , <bad-url-token> , tidak tertandingi <)-token> , <]-token> , atau <}-token> , atau level teratas <semicolon-token> token atau <delim-token> token dengan nilai "!".

Jadi, kesimpulan penting adalah:

1. Hanya tanda titik koma tingkat atas yang penting. Saya menafsirkannya sebagai "tidak dalam pasangan lain yang cocok"? Tapi saya bisa saja salah mengartikan apa yang dimaksud dengan "level atas".

2. Mungkin contoh JS yang diberikan pada halaman itu menyesatkan, ( -foo: if(x > 5) this.width = 10; valid.) Tetapi = yang tidak diberi spasi jelas bukan token CSS biasa, juga bukan this.width . Tanpa klarifikasi, dan mengingat seberapa permisif pemulihan kesalahan di browser, saya rasa kami tidak dapat mengasumsikan kesalahan penguraian apa pun untuk apa pun. Kami _sudah tahu_ bahwa sintaks @apply valid (dengan sekumpulan aturan), meskipun memiliki aplikasi kustom. Jadi kita tahu bahwa properti kustom memungkinkan beberapa titik koma dalam {} ; Oleh karena itu logis bahwa bahasa ini menyiratkan sesuatu tentang sifat permisif dalam pencocokan () , [] , {} . Ada banyak hal yang tidak kita ketahui di sini, dan tanpa mengetahui _apa_ yang dapat dimasukkan ke dalam properti kustom, saya rasa kita harus berasumsi bahwa apa pun bisa masuk ke dalamnya, selama mengikuti struktur tertentu ("asalkan urutannya tidak berisi <bad-string-token> , <bad-url-token> , <)-token> , <]-token> , atau <}-token> ") dan teruskan properti tersebut ke browser. Saya percaya maksud di sini adalah untuk menciptakan fleksibilitas maksimum bagi pengembang, sekaligus menciptakan persyaratan minimum untuk penguraian yang berhasil.

Jadi, Anda tidak bisa melakukan ini:

.bar {
  --foo: {;
  --baz: ";
}

... karena sintaks ingin mengizinkan Anda memasukkan apa saja, termasuk beberapa titik koma, tetapi ingin mengetahui saat Anda selesai. Di situlah tanda kutip / kurung kurawal / kurung yang cocok ikut bermain. Selama Anda dapat menunjukkan bahwa Anda telah "menutup" sintaks Anda dengan cara tertentu, saya yakin maksudnya di sini adalah bahwa Anda dapat melakukan apa yang Anda inginkan dalam sintaks itu.

Mengenai ini:

adalah salah satu dari --var:?;, --var: (?); atau --var: [¾]; sah?

Saya tidak tahu.

Haruskah kita memperlakukannya sebagai valid? IMO ya. Karena kita tidak / tidak bisa tahu, tapi kita _dapat_ berhasil menguraikannya tanpa terlalu banyak kesulitan.

Adapun implementasi yang mungkin ... Bukan masalah besar untuk mengizinkan apa pun di sana hingga ; tetapi kemudian kita masih harus menangani setidaknya string, url, dan bertumpuk {} (karena mungkin berisi ; di dalam). Jelas ini berarti tidak ada kode Kurang di dalamnya.

Langkah selanjutnya adalah memperlakukannya (pada tahap penguraian) sebagai semacam DR (tanpa {} luarnya) dengan hanya lebih banyak token yang diizinkan (meskipun ini terlihat seperti jalan mati karena Anda bisa ' t gunakan kembali DR-parser untuk sesuatu seperti --var: (1 > 2) / {whatever} foo; )

Dan akhirnya, untuk sesuatu yang lebih nyaman, sejujurnya saya tidak dapat melihat apa pun kecuali menulis CSS-tokeniser berfitur lengkap dengan beberapa fitur Less (token dan kemudian evaluasi mereka) diperbolehkan masuk. Masalah biiiiiiiig dengan kata lain :(

Hanya tanda titik koma tingkat atas yang penting. Saya menafsirkannya sebagai "tidak dalam pasangan lain yang cocok"? Tapi saya bisa saja salah mengartikan apa yang dimaksud dengan "level atas".

Ya, saya cukup yakin ini tentang penghentian ; . Yaitu: --var: ";" url(;) {;}; valid dan --var: ; {} foo; tidak ( ; dengan menjadi "top-level" mengakhiri pernyataan).
Saya tidak yakin tentang hanya (;) sekalipun.

Jelas ini berarti tidak ada kode Kurang di dalamnya.

Satu-satunya pemikiran saya adalah bahwa kami mungkin mungkin mengizinkan sintaks interpolasi, jika Anda ingin membuat properti kustom. Tapi mungkin itu semacam ide "putaran kedua jika ada minat".

Saya tidak yakin tentang hanya (;) sekalipun.

Saya juga tidak? Saya percaya spesifikasi sering memiliki detail penguraian yang diterbitkan di suatu tempat (seperti diagram jalur token), tetapi saya tidak yakin apakah itu ada dalam kasus ini. Sebagai tahap 1 - hanya membutuhkan pencocokan {} , () , dan tanda kutip, dan membuang apa pun ke simpul anonim sampai tingkat atas ; tampaknya baik-baik saja. Tanda kurung yang cocok [] mungkin tidak diperlukan, tetapi mereka juga disebutkan dan itu cukup sepele setelah semua bagian lainnya ada di sana.

Saya tidak berpikir kita perlu secara khusus membuat tokenisasi apa pun, atau mencampurkan ini dengan barang DR. Bagaimanapun, seseorang bisa saja berakhir dengan:

.weird {
  --php: ($x = 5 /* + 15 */ + 5; echo $x;);
  --example: [My DR will be --this: { 
    blah: nope;
    --never mind i gave up;
    no wait here it --is: {
      lol: cats;
    }
  }];
}

Dengan kata lain, akan lebih baik bagi Less untuk membersihkan tangannya dari menangani konten properti kustom.

Selain itu, secara teknis mungkin bagi pembuat plugin Less untuk menulis plugin pengunjung yang mengambil bagian dan mengirimkan kembali properti kustom yang cocok melalui Less parser untuk membuat node baru. Yang harus kita lakukan adalah membuang konten ke node aturan dan menandai aturan sebagai properti khusus, lalu membuang hasilnya dengan setia.

Perhatikan bahwa jika kita memodifikasi contoh di atas, INI harus dianggap tidak valid:

.weird {
  --example: [My DR will be --this: { 
    blah: nope;
    --never mind i gave up;
    no wait here it --is: {
      lol: cats;
   // missing matching }
  }];
}

"no Less code"

Mungkin, tetapi ini berarti penurunan peringkat - seperti sekarang orang dapat menulis:
--var: darken(red, 5%) + 1;
dan berhasil, tetapi kemudian (demi --fortran: read (*, *, iostat=ierr) radius, height; ) tidak akan :(

Kami dapat memiliki opsi untuk ini mungkin (seperti --oh-no-yet-another-option-for-custom-properties-to-be-parsed-one-way-or-another: on :)

Mungkin, tetapi ini berarti penurunan peringkat - seperti sekarang orang dapat menulis --var: darken (merah, 5%); dan berhasil, tetapi kemudian (demi --fortran: read (*, *, iostat = ierr) radius, height;) tidak akan :(

🤔 Yah ..... ya saya mengerti maksud Anda, itulah mengapa mungkin interpolasi mungkin diperlukan? Kami pada dasarnya di parser memperlakukan hal-hal yang mirip dengan:

<strong i="8">@iostat</strong>: ierr;
--fortran: read (*, *, iostat=@{iostat}) radius, height;

// treat similar to:
--fortran: ~"read (*, *, iostat=@{iostat}) radius, height";

(Dengan peringatan yang disebutkan di atas tentang token pencocokan yang tepat?)

Maksud saya .... alternatifnya adalah kami pada dasarnya merekomendasikan pelolosan sintaksis. Akan lebih baik untuk lebih sedikit modifikasi kode CSS di tempat.

Ya, interpolasi akan berhasil. Meskipun masih akan menyenangkan untuk mengurai DR-ike sebagai opsi eksperimental (saya cukup yakin banyak yang akan lebih suka --var: darken(red, 5%); nyata daripada --javascript: 1 = 2; setidaknya sampai peretasan properti khusus seperti itu tersebar luas: )

Dengan kata lain, saya baik-baik saja dengan kedua cara (secara terpisah atau bersamaan).

Saya rasa saya memiliki implementasi / solusi yang cukup kuat untuk ini. Saya menggunakan sejumlah contoh kode dari utas ini dalam pengujian. Jadi, nilai properti kustom dan at-rules yang tidak diketahui pada dasarnya diperlakukan sebagai nilai kutipan yang lolos untuk memungkinkan interpolasi. Lihat # 3213.

Tetap.