Kueri Elemen, Dan Bagaimana Anda Dapat Menggunakannya Hari Ini

Pikirkan sejenak struktur fisik. Jika Anda sedang membangun sebuah bangunan besar dengan bahan yang lemah, banyak dukungan eksternal diperlukan untuk menahannya bersama-sama, dan segala sesuatunya harus dibangun berlebihan agar tetap kokoh. Saat Anda membuat situs web dari HTML, CSS, dan JavaScript, dukungan eksternal ini mungkin terlihat seperti kerangka kerja, plugin, praprosesor, transpiler, alat pengeditan, pengelola paket, dan proses pembuatan.

Alih-alih menambahkan plugin lain ke tumpukan teratas, saya bertanya-tanya apakah, dengan memperluas salah satu bahasa inti, CSS , kami dapat memperkuat materi yang digunakan untuk membuat situs web, mengembangkan situs web yang lebih baik dan lebih kuat yang memerlukan lebih sedikit dukungan dan alat eksternal untuk membangun.

Status Query Elemen Saat Ini

Dengan alat seperti praprosesor CSS, kami menulis CSS dalam bentuk singkat, untuk kemudian diperluas ke bentuk lengkapnya (sebelum dilihat di browser). Plugin dapat beroperasi pada halaman bersama elemen yang dipengaruhinya, tetapi untuk menerapkan gaya, mereka menulis gaya CSS langsung ke HTML atau mengganti nama kelas yang menerapkan aturan CSS yang berbeda. Dalam kedua kasus tersebut, kita perlu menulis atau membuat CSS yang akan kita perlukan sebelum halaman benar-benar dimuat.

Masalah

Masalah dengan metode ini adalah bahkan plugin terbaik pun sering kali memerlukan penyesuaian dan konfigurasi di setiap tata letak yang Anda gunakan. Juga, ketika JavaScript menulis gaya untuk Anda, mungkin sulit untuk menjaga logika berbasis plugin dan gaya CSS Anda bersama-sama saat memfaktorkan ulang atau menggunakan kembali kode.

Masalah lain dengan praprosesor adalah bahwa setiap kesalahan yang ditulis dengan cepat akan menjadi kekacauan yang jauh lebih besar setelah CSS diperluas ke bentuk penuhnya. Saat menggunakan plugin, kami menambahkan banyak titik kegagalan potensial. Kami mungkin menggunakan beberapa plugin untuk menyelesaikan beberapa hal berbeda yang mungkin tidak diperlukan jika CSS sedikit lebih kuat. Ini menciptakan beban ekstra bagi pengembang untuk dipelihara, untuk dirender oleh browser, dan untuk diunduh oleh pengguna.

Apakah Ada Harapan untuk Masa Depan Pengembangan Web?

Pada tahun 2013, Tyson Matanich menulis sebuah artikel berjudul “Media Queries Bukanlah Jawabannya: Element Query Polyfill,” yang memperkenalkan konsep elemen query kepada khalayak luas. Ini memulai diskusi tentang bagaimana plugin dan polyfill dapat dibangun untuk menavigasi kekurangan CSS.

Sejak itu, sementara kami menunggu fitur CSS untuk maju, sejumlah plugin telah dirilis yang memungkinkan pengembang untuk menggunakan kueri elemen dalam beberapa cara berbeda.

Apa itu Kueri Elemen?

Kueri elemen seperti kueri media, kecuali bahwa aturannya berlaku untuk properti elemen sebenarnya, bukan properti viewport browser.

Bagaimana EQCSS Muncul

Pada akhir 2013, saya mendapati diri saya bekerja di bagian depan aplikasi web Ruby on Rails. Aplikasi perlu menampilkan informasi mendetail kepada pengguna, dan tujuannya adalah untuk membangun antarmuka responsif yang akan bekerja sama baiknya di ponsel, tablet, dan browser desktop. Ini menimbulkan beberapa tantangan, salah satunya adalah bahwa sebagian besar konten penting yang akan ditampilkan paling baik ditampilkan dalam tabel — ya, elemen table yang sebenarnya (untuk menunjukkan transaksi keuangan, catatan olahraga, dll.).

Saya membuat gaya responsif menggunakan kueri media yang menampilkan elemen table dengan benar untuk browser dengan ukuran berbeda. Tapi begitu salah satu tabel responsif itu ditampilkan dalam template yang berisi sidebar, tiba-tiba semua breakpoint responsif saya berubah menjadi breakpoint responsif. Mereka tidak memperhitungkan bilah sisi selebar 200 piksel, menyebabkan banyak hal tumpang tindih dan tampak rusak.

Kendala lain: Panjang nama pengguna bervariasi dari 3 hingga 20 karakter, dan saya berharap dapat menyesuaikan ukuran font setiap nama pengguna secara otomatis berdasarkan jumlah karakter yang ada di dalamnya. Saya perlu meletakkan setiap nama pengguna di bilah sisi, dan sulit untuk memilih ukuran font yang cukup kecil untuk memuat nama pengguna 20 karakter tetapi cukup besar bagi pemirsa untuk melihat nama pengguna 3 karakter.

Untuk mengatasi masalah seperti ini, saya sering mendapati diri saya menyalin seluruh kueri media, menduplikasi sebagian besar basis kode saya, hanya karena saya membutuhkan cara yang lebih cerdas untuk menerapkan gaya responsif di setiap tata letak. Saya mengandalkan JavaScript sebagai solusi darurat lainnya, menulis banyak fungsi yang hampir identik yang akan menonton halaman dan menerapkan gaya di tempat-tempat yang tidak dapat dijangkau oleh CSS. Setelah beberapa saat, beban tambahan dari semua kode duplikat ini mulai membebani basis kode dan membuat perubahan sulit dilakukan.

Saya tahu harus ada solusi yang lebih baik, dan setelah beberapa saat saya mulai berpikir: Saya tidak memerlukan kueri media — yang saya butuhkan adalah kueri elemen!

Penelitian dan Pengembangan

Sepanjang tahun 2014, saya mulai bereksperimen dengan berbagai cara untuk menginformasikan CSS tentang properti elemen saat muncul di halaman, sehingga saya bisa menerapkan gaya yang lebih baik. Saya berharap menemukan pendekatan yang memungkinkan saya untuk menulis gaya yang menggabungkan keindahan CSS dengan kekuatan JavaScript.

Beberapa pendekatan terbengkalai yang saya tinggalkan termasuk menambahkan atribut ke tag HTML untuk menambahkan dukungan responsif, dan mencoba menemukan cara untuk menyematkan seluruh blok kode CSS di dalam pernyataan if berbasis JavaScript untuk menghasilkan semacam monster Frankenstein yang ditambal bersama dari JavaScript dan CSS.

Tetapi alih-alih membuat segalanya lebih mudah, semua pendekatan saya yang gagal memiliki satu kesamaan: Mereka menambahkan lebih banyak pekerjaan! Saya tahu bahwa solusi yang tepat akan menyederhanakan dan mengurangi pekerjaan yang harus diselesaikan, jadi saya terus mencari. Melalui eksperimen ini, saya mendapatkan ide yang disempurnakan tentang jenis sintaks yang diperlukan agar kueri elemen berfungsi dengan baik.

Seperti yang disebutkan, untuk situs web yang dibangun dari HTML, CSS, dan JavaScript, dukungan eksternal datang dalam bentuk kerangka kerja, plugin, praprosesor, transpiler, alat pengeditan, pengelola paket, dan proses pembuatan. Alih-alih menambahkan plugin lain ke tumpukan teratas, saya bertanya-tanya apakah, dengan memperluas salah satu bahasa inti, CSS, kita dapat memperkuat materi yang digunakan untuk membangun situs web, membangun situs web yang lebih baik dan lebih kuat yang memerlukan lebih sedikit dukungan eksternal dan alat untuk membangun.

Kelahiran Sebuah Sintaks

Pada akhir 2014, dilengkapi dengan visi yang lebih baik dari sintaks yang dibutuhkan, saya menghubungi Maxime Euziere, pegolf kode JavaScript yang fenomenal dan menanyakan pendapatnya tentang kemungkinan memperluas CSS menggunakan JavaScript di browser saat runtime. Dia tidak hanya memberi tahu saya bahwa itu mungkin, tetapi dia menawarkan untuk membantu saya melakukannya! Kami menamai sintaks EQCSS, kependekan dari "element query CSS." Nama ini juga mengacu pada kata "berlebihan", karena semua yang dilakukannya melebihi apa yang dapat dilakukan CSS.

Kebutuhan

Persyaratan saya untuk sintaks adalah sedekat mungkin dengan CSS — begitu dekat sehingga penyorot sintaks akan tertipu dengan menganggapnya sebagai CSS standar. Jadi, saya memetakan sintaks CSS untuk kueri elemen yang masuk akal — jenis sintaks yang membuat orang terkejut belum ada.

Saya tahu bahwa jika kita akan memperluas dukungan browser untuk CSS menggunakan JavaScript, maka plugin harus seringan dan semudah mungkin untuk menyelesaikan pekerjaan, yang mengesampingkan penggunaan perpustakaan seperti jQuery untuk membangun plugin. Saya membutuhkan perpustakaan JavaScript murni yang akan menambahkan fitur yang saya inginkan di masa mendatang ke dalam browser yang harus saya dukung hari ini.

Saat ini, diskusi di komunitas CSS difokuskan pada aturan @ khusus, dan pembicaraan tentang kueri elemen masih bersifat pendahuluan. Kami mungkin masih bertahun-tahun lagi dari spesifikasi CSS resmi untuk fitur seperti ini, dan bahkan setelah spesifikasi, kami masih perlu menunggu dukungan browser yang cukup sebelum kami dapat menggunakan fitur tersebut di situs web.

Menunggu fitur ini ditambahkan ke CSS tidak masuk akal saat kami membutuhkan fungsi ini untuk membangun dan memperbaiki situs web hari ini.

Hasil

Hasil dari penelitian ini adalah pembuatan sintaks yang mencakup kumpulan baru kondisi responsif lanjutan, gaya cakupan dan pemilih baru untuk elemen penargetan, serta pustaka JavaScript murni bernama EQCSS.js. Plus, dukungan untuk Internet Explorer (IE) 8 telah disediakan dalam polyfill eksternal opsional. Baik plugin dan polyfill telah dirilis di bawah lisensi MIT dan gratis untuk digunakan semua orang.

Gunakan Kasus Untuk Kueri Elemen

Pengembang Plugin

Saat membuat komponen dan widget UI, pengembang sering kali menemukan diri mereka dibatasi oleh kueri media. Kita sering harus memilih antara membangun banyak tata letak berbeda yang dapat dikonfigurasi oleh orang yang menggunakan plugin, dan menyederhanakan antarmuka hingga Anda dapat membangun solusi satu ukuran yang paling sesuai.

Namun saat mendesain plugin dan antarmuka dengan kueri elemen, kita dapat dengan mudah menulis gaya responsif yang mencakup semua situasi yang kita antisipasi, menjadikannya benar-benar antipeluru, tidak peduli konten apa yang dimasukkan pengguna ke dalam atau di mana plugin muncul. Misalkan kita dapat menata widget dengan tata letak mulai dari lebar 150 hingga 2000 piksel. Kemudian, di mana pun widget itu ditampilkan di situs web, itu akan selalu terlihat bagus.

Pembuat Template

Saat Anda membuat prototipe situs web, biasanya mengatur ulang elemen desain pada halaman dan menganggap desain sebagai kumpulan komponen modular. Jika Anda telah menulis kueri media CSS, terkadang ini bisa menjadi kasus pengoptimalan prematur . Dengan mendesain dengan kueri elemen, Anda menjaga kondisi responsif yang tidak bergantung pada tata letak, memberi Anda lebih banyak fleksibilitas untuk memindahkan berbagai hal tanpa harus terlalu banyak mengerjakan ulang gaya.

Hal-hal yang menurut saya sangat berguna untuk dirancang atau dibuat tiruan menggunakan kueri elemen meliputi:

• bilah navigasi,
• modal,
• formulir pendaftaran dan login,
• catatan kaki,
• grafik harga,
• halaman arahan,
• tabel,
• kotak tab,
• akordeon,
• widget bilah sisi,
• pemutar media,
• bagian testimoni.

Elemen desain apa pun dapat "dicakup" dan dipindahkan ke mana saja — halaman ke halaman atau situs web ke situs web.

Dukungan Perangkat

Salah satu masalah yang Anda hadapi saat mendukung web di perangkat seluler adalah banyaknya perangkat keras. Pasar perangkat lebih terfragmentasi daripada sebelumnya, dan perangkat baru muncul setiap hari. Kami tidak dapat lagi mempertahankan daftar browser dan perangkat yang kami dukung, jadi penting untuk mengetahui bahwa desain berfungsi di mana saja, bahkan pada perangkat yang belum dirilis.

Dengan menggunakan kueri elemen, Anda dapat mendesain situs web dengan cara yang lebih baik dan menghilangkan beberapa perbedaan lintas-browser ini.

Banyak artikel yang ditulis baru-baru ini tentang perlunya kueri elemen menggambarkan banyak kasus penggunaan secara rinci. Jadi, mari kita lanjutkan dengan cara menggunakannya!

Cara Menulis Kueri Elemen

Memulai dengan EQCSS itu mudah. Yang Anda butuhkan untuk mulai menggunakan sintaks EQCSS adalah memasukkan JavaScript di suatu tempat di HTML Anda.

Mengunduh EQCSS.js

Jika Anda ingin mengkloning proyek EQCSS dari GitHub, Anda dapat mengetik:

 git clone https://github.com/eqcss/eqcss.git

Jika Anda menggunakan npm, Anda dapat menambahkan EQCSS ke proyek Anda dengan perintah berikut:

 npm install eqcss

Menambahkan EQCSS.js ke HTML Anda

Setelah Anda mengunduh EQCSS, Anda dapat menambahkannya ke HTML Anda dengan tag script :

 <script src="EQCSS.js"></script>

File ini ( EQCSS.js ) menyertakan dukungan untuk semua browser saat ini, termasuk IE 9 dan yang lebih baru. Untuk mendukung IE 8, kita harus menggunakan banyak polyfill lainnya. Ingatlah bahwa IE 8 bahkan tidak mendukung kueri media CSS tanpa polyfill, jadi cukup menakjubkan bahwa kami juga bisa membuat kueri elemen berfungsi di sana. Untuk menyertakan dukungan IE 8 untuk situs web yang menggunakan EQCSS, tambahkan tautan berikut sebelum tautan Anda ke plugin utama:

 <!‐‐[if lt IE 9]><script src="EQCSS‐polyfills.js"></script><![endif]‐‐>

Menjalankan EQCSS

Secara default, plugin EQCSS akan menghitung gaya apa pun yang ditemukannya setelah halaman dimuat, dan juga setiap kali mendeteksi browser sedang diubah ukurannya, mirip dengan kueri media. Anda juga dapat memanggil EQCSS.apply() secara manual dengan JavaScript untuk menghitung ulang gaya kapan saja, yang dapat berguna setelah konten diperbarui pada halaman.

Menulis Elemen Kueri CSS

Plugin EQCSS.js dapat membaca gaya dalam beberapa cara berbeda. Anda dapat menyertakan EQCSS dalam tag style apa pun pada halaman HTML. Anda juga dapat menulis EQCSS dalam style sheet CSS eksternal.

Jika Anda ingin memisahkan kode yang didukung EQCSS dari CSS, Anda dapat memuat sintaks EQCSS menggunakan tag script dengan jenis yang disetel ke text/eqcss . Anda dapat menambahkan gaya sebaris dalam tag seperti ini, atau menautkan ke lembar gaya .eqcss eksternal dengan <script type=“text/eqcss” src=styles.eqcss></script> , yang akan memuat file bernama styles.eqcss .

Anatomi Query Elemen

Lingkup Gaya

Sintaks dalam EQCSS untuk menulis kueri elemen sangat mirip dengan pemformatan kueri media CSS, tetapi alih-alih @media , kami memulai kueri dengan @element . Satu-satunya informasi lain yang perlu kami berikan adalah setidaknya satu pemilih tempat gaya ini harus diterapkan. Inilah cara Anda membuat cakupan baru untuk elemen bernama <div class=“widget”> :

 @element '.widget' { }

Elemen di antara tanda kutip (dalam hal ini, .widget ) dapat berupa pemilih CSS yang valid. Dengan kueri ini, kami telah membuat cakupan baru pada elemen .widget . Kami belum menyertakan kondisi responsif apa pun untuk cakupan, jadi gaya apa pun dalam kueri seperti ini akan diterapkan ke elemen cakupan setiap saat.

Tanpa kemampuan untuk memberikan cakupan gaya ke satu atau beberapa elemen (bukan seluruh halaman sekaligus), kami tidak akan dapat menerapkan kueri responsif hanya ke elemen tersebut. Setelah kita membuat cakupan level elemen itu, menggunakan fitur sintaks EQCSS yang lebih canggih menjadi mudah — seperti $parent meta selector, misalnya — karena JavaScript sekarang memiliki titik referensi untuk menghitung hal-hal seperti parentNode dari scoped elemen. Ini sangat besar!

Benar, CSS sudah menyertakan pemilih turunan langsung, dengan > , yang memungkinkan kita memilih elemen yang merupakan turunan langsung dari elemen yang ditentukan. Tetapi CSS saat ini tidak menawarkan cara untuk melakukan perjalanan ke arah lain ke atas pohon keluarga, untuk memilih elemen yang berisi elemen lain, yang akan disebut elemen induknya. Spesifikasi "CSS Selectors Level 4" sekarang menyertakan pemilih :has() , yang bekerja dengan cara yang mirip dengan pemilih :has() jQuery, tetapi saat ini dukungan browser nihil. Lingkup CSS memungkinkan jenis pemilih induk yang berbeda.

Sekarang setelah kita membuka cakupan dalam konteks elemen .widget , kita dapat menulis gaya dari perspektifnya untuk menargetkan elemen induknya sendiri:

 @element '.widget' { $parent { /* These styles apply to the parent of .widget */ } }

Contoh lain dari selektor khusus yang dapat digunakan dalam kueri elemen apa pun adalah selektor $prev dan $next , yang mewakili elemen saudara sebelumnya dan berikutnya. Meskipun CSS dapat menjangkau saudara berikutnya dari widget kita dengan pemilih seperti .widget + * , tidak ada cara dalam CSS untuk mundur dan memilih elemen yang datang langsung sebelum elemen lain.

 <section> <div>This will be the previous item</div> <div class="widget">This is the scoped element</div> <div>This will be the next item</div> </section> <style> @element '.widget' { $prev { /* These styles apply to the element before .widget */ } $next { /* These styles apply to the element after .widget */ } } </style>

Pertanyaan Elemen

Pengembang paling sering menggunakan kueri media CSS untuk desain responsif dengan menerapkan gaya berdasarkan tinggi atau lebar area pandang browser. Sintaks EQCSS mendukung banyak jenis kondisi responsif baru. Alih-alih bekerja dengan lebar dan tinggi browser saja, Anda dapat menulis gaya yang berlaku untuk elemen berdasarkan propertinya sendiri, seperti berapa banyak elemen anak yang dikandungnya, atau berapa banyak karakter atau baris teks dalam elemen saat ini .

Menambahkan ketentuan responsif ini ke gaya cakupan Anda mirip dengan cara Anda memformat kueri media: Anda akan menambahkan and (condition: value) untuk setiap ketentuan yang ingin Anda periksa. Dalam contoh ini, kami akan memeriksa apakah ada elemen .widget yang menampilkan setidaknya 500 piksel lebar pada halaman.

 @element '.widget' and (min‐width: 500px) { /* CSS rules here */ }

Sintaks kueri elemen dipecah sebagai berikut:

• query elemen @element selector_list [ condition_list ] { css_code }
• daftar pemilih " css selector [ "," css selector ]* "
• daftar kondisi and ( query_condition : value ) [ "and (" query condition ":" value ")" ]*
• nilai number [ css unit ]
• kondisi kueri tinggi min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x
• satuan css % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax

Sebagai contoh lain, berikut ini cara menulis kueri yang mengubah elemen body menjadi merah saat elemen .widget mencapai lebar 500 piksel:

 @element '.widget' and (min‐width: 500px) { body { background: red; } }

Perhatikan bahwa elemen body berubah ketika .widget mencapai lebar tertentu, bukan elemen .widget itu sendiri!

Ketentuan Kueri Elemen

Di bawah ini adalah daftar lengkap kondisi responsif yang didukung EQCSS.

Kondisi Berbasis Lebar

• demo min-width untuk piksel, demo untuk persentase
• demo max-width untuk piksel, demo untuk persentase

Kondisi Berbasis Tinggi

• demo min-height untuk piksel, demo untuk persentase
• demo max-height untuk piksel, demo untuk persentase

Kondisi Berbasis Hitungan

• demo min-characters untuk elemen blok, demo untuk input formulir
• demo max-characters untuk elemen blok, demo untuk input formulir
• demo min-lines
• demo max-lines
• demo min-children
• demo max-children

Ketentuan Berbasis Gulir

• demo min-scroll-y
• demo max-scroll-y
• demo min-scroll-x
• demo max-scroll-x

Anda dapat menggabungkan sejumlah kondisi ini dalam kueri elemen Anda untuk gaya responsif multidimensi yang sesungguhnya. Ini memberi Anda lebih banyak fleksibilitas dan kontrol atas bagaimana elemen dirender. Misalnya, untuk mengecilkan ukuran font header yang memiliki lebih dari 15 karakter saat ruang yang tersedia kurang dari 600 piksel, Anda dapat menggabungkan ketentuan untuk max‐characters: 15 dan max‐width: 600px 600 piksel :

 h1 { font‐size: 24pt; } @element 'h1' and (min‐characters: 16) and (max‐width: 600px) { h1 { font‐size: 20pt; } }

Pemilih Meta

Salah satu masalah yang mungkin Anda temui setelah Anda mulai menulis gaya cakupan dengan kondisi responsif adalah, ketika beberapa contoh pemilih yang sama ada di halaman, menggunakan pemilih itu dalam kueri elemen Anda akan menerapkan gaya ke semua contoh pemilih itu di halaman ketika salah satu dari mereka cocok dengan kondisi. Mengambil contoh .widget kami dari sebelumnya, misalkan kami memiliki dua widget di halaman (mungkin satu di bilah sisi dan yang lain ditampilkan dengan lebar penuh) dan kami menulis kueri elemen kami seperti ini:

 @element '.widget' and (min‐width: 500px) { .widget h2 { font‐size: 14pt; } }

Ini berarti bahwa ketika salah satu elemen .widget pada halaman memiliki lebar minimal 500 piksel, gaya akan diterapkan ke kedua elemen .widget . Ini mungkin bukan yang kita inginkan terjadi dalam banyak kasus. Di sinilah penyeleksi meta masuk!

Dua bagian yang membentuk kueri elemen kami adalah pemilih dan kondisi responsif. Jadi, jika kita hanya ingin menargetkan elemen pada halaman yang cocok dengan pemilih dan kondisi responsif secara bersamaan, kita dapat menggunakan pemilih meta $this . Kita dapat menulis ulang contoh terakhir kita sehingga gaya hanya berlaku untuk elemen .widget yang cocok dengan kondisi min‐width: 500px :

 @element '.widget' and (min‐width: 500px) { $this h2 { font‐size: 14pt; } }

Sejumlah pemilih baru didukung oleh sintaks EQCSS yang tidak ada di CSS biasa. Berikut daftar lengkapnya:

• $this
• $parent
• $root demo
• $prev demo
• $next

Selektor ini hanya akan berfungsi dalam kueri elemen.

Membuka Portal Antara JavaScript dan CSS

• eval(') demo

Fitur terakhir dan terakhir dari EQCSS adalah yang paling liar: eval(') . Melalui pintu ini terletak semua kekuatan JavaScript, dapat diakses dari CSS. Meskipun JavaScript dapat menerapkan gaya ke elemen, saat ini sulit untuk mencapai beberapa hal, seperti elemen semu :before dan :after . Tetapi bagaimana jika CSS dapat menjangkau JavaScript dari arah lain? Alih-alih JavaScript mengatur properti CSS, bagaimana jika CSS dapat mengetahui JavaScript?

Di sinilah eval(') masuk. Anda dapat mengakses dan mengevaluasi JavaScript apa pun, apakah akan menggunakan nilai variabel JavaScript di CSS Anda, untuk menjalankan JavaScript satu baris (seperti eval('new Date().getFullYear()') ), untuk memastikan nilai tentang browser dan elemen lain yang dapat diukur JavaScript (seperti eval('innerHeight') ) atau untuk menjalankan fungsi JavaScript dan menggunakan nilai yang dikembalikan dalam gaya CSS Anda. Berikut adalah contoh yang menampilkan 2016 dalam elemen <footer> :

 @element 'footer' { $this:after { content: " eval('new Date().getFullYear()')"; } }

Menggunakan $it di dalam eval(')

Saat mengevaluasi JavaScript, eval(') juga bekerja dari konteks elemen yang dicakup secara aktif, elemen yang sama dengan gaya $this yang berlaku. Anda dapat menggunakan $it dalam JavaScript yang ditulis dalam eval(') sebagai pengganti untuk elemen cakupan jika ini membantu Anda menyusun kode, tetapi jika dihilangkan, itu akan bekerja dengan cara yang sama. Sebagai contoh, katakanlah kita memiliki div dengan kata "halo" di dalamnya. Kode berikut akan menampilkan "halo halo":

 <div>hello</div> <style> @element 'div' { div:before { content: "eval('$it.textContent') "; } } </style>

Di sini, $it merujuk ke div karena ini adalah pemilih yang dicakup saat ini. Anda juga dapat menghilangkan $it dan menulis kode berikut untuk menampilkan hal yang sama:

 @element 'div' { div:before { content: "eval('textContent') "; } }

eval(') dapat membantu dalam situasi di mana CSS tidak mengetahui pengukuran atau peristiwa yang terjadi pada halaman setelah dimuat. Misalnya, elemen iframe yang digunakan untuk menyematkan video YouTube memiliki lebar dan tinggi yang ditentukan. Meskipun Anda dapat mengatur lebar menjadi auto di CSS, tidak ada cara mudah untuk mempertahankan rasio aspek lebar dan tinggi yang benar saat video diperluas untuk mengisi ruang yang tersedia.

Solusi umum untuk mempertahankan rasio aspek responsif saat penskalaan adalah menempatkan konten yang perlu mempertahankan rasio aspeknya dalam pembungkus, lalu menambahkan bantalan ke pembungkus dengan nilai berdasarkan rasio lebar terhadap tinggi yang ingin Anda pertahankan. Ini berfungsi, tetapi mengharuskan Anda untuk mengetahui rasio aspek semua video terlebih dahulu, serta memerlukan lebih banyak markup HTML (elemen pembungkus) untuk setiap video yang ingin Anda sematkan secara responsif. Lipat gandakan itu di setiap situs web yang memiliki video responsif, dan itu banyak kesalahan yang tidak perlu ada jika CSS sedikit lebih pintar.

Mungkin pendekatan yang lebih baik untuk rasio aspek responsif melibatkan penempatan setiap video dalam pembungkus tanpa bantalan dan kemudian menulis pustaka JavaScript yang menghitung rasio aspek setiap video yang ditemukannya dan menerapkan jumlah bantalan yang benar untuk setiap pembungkus.

Tetapi bagaimana jika CSS dapat mengakses pengukuran tersebut secara langsung? Kami tidak hanya dapat menggabungkan CSS untuk semua rasio aspek yang berbeda menjadi satu aturan, tetapi jika kami dapat mengevaluasinya setelah halaman dimuat, kami dapat menulis satu aturan yang secara responsif mengubah ukuran video apa pun yang pernah kami berikan di masa mendatang. Dan kita bisa melakukan semuanya tanpa pembungkus!

Jika ini tampaknya terlalu bagus untuk menjadi kenyataan, periksa ini. Inilah betapa sederhananya menulis elemen iframe tanpa pembungkus yang responsif dan responsif di EQCSS:

 @element 'iframe' { $this { margin: 0 auto; width: 100%; height: eval('clientWidth/(width/height)'); } }

Di sini, width dan height mengacu pada atribut width=“” dan height=“” di iframe dalam HTML. JavaScript dapat melakukan perhitungan (width/height) , yang memberi kita rasio aspek; dan untuk menerapkannya pada lebar berapa pun, kami hanya akan membagi lebar elemen iframe saat ini dengan rasionya.

Ini memiliki keringkasan dan keterbacaan CSS, dan semua kekuatan JavaScript. Tidak diperlukan pembungkus tambahan, tidak ada kelas tambahan dan tidak ada CSS tambahan.

Hati-hati dengan eval(') . Ada alasan mengapa ekspresi CSS dianggap berbahaya di masa lalu, dan ada juga alasan mengapa kami mencoba ide tersebut. Jika Anda tidak berhati-hati dengan berapa banyak elemen yang Anda terapkan pada halaman atau dengan seberapa sering Anda menghitung ulang gaya, maka JavaScript bisa berakhir dengan menjalankan sesuatu ratusan kali lebih banyak dari yang dibutuhkan. Untungnya, EQCSS memungkinkan kita untuk memanggil EQCSS.apply() atau EQCSS.throttle() untuk menghitung ulang gaya secara manual, sehingga kita memiliki kontrol lebih besar saat gaya diperbarui.

Zona Bahaya!

Masalah lain dapat terjadi jika Anda membuat kueri dengan kondisi atau gaya yang bertentangan. EQCSS, seperti CSS, dibaca dari atas ke bawah menggunakan hierarki kekhususan. Meskipun CSS adalah bahasa deklaratif, CSS memiliki beberapa fitur lanjutan. Hanya beberapa langkah lagi untuk menjadi lengkap Turing sebagai bahasa pemrograman. Sejauh ini, debugging CSS telah menjadi urusan yang cukup mudah, tetapi EQCSS menggeser CSS dari sekadar bahasa deklaratif yang ditafsirkan menjadi bahasa lembar gaya dinamis dengan lapisan interpretasi tambahan antara CSS dan browser. Dengan wilayah baru ini muncul berbagai potensi jebakan baru.

Berikut adalah contoh loop timbal balik di EQCSS, sesuatu yang desainnya kebal terhadap kueri media CSS normal:

 @element '.widget' and (min‐width: 300px) { $this { width: 200px; } }

Saya menyebutnya jekyll: hide; CSS. Namun selain satu gaya yang terus memicu dirinya sendiri, ada juga kemungkinan menulis beberapa kueri yang memicu satu sama lain, dalam apa yang kami sebut "loop timbal balik terbalik ganda", yang paling menjijikkan dari semuanya:

 @element '.widget' and (min‐width: 400px) { $this { width: 200px; } } @element '.widget' and (max‐width: 300px) { $this { width: 500px; } }

Secara teori, widget yang malang itu akan terjebak dalam satu lingkaran, mengubah ukuran antara 200 dan 500 piksel hingga akhir waktu, tidak dapat menetapkan lebar. Untuk kasus seperti ini, EQCSS hanya menghitung aturan dalam urutan mereka dievaluasi, penghargaan pemenang dan melanjutkan. Jika Anda mengatur ulang urutan munculnya aturan-aturan ini, gaya yang terakhir akan selalu menang jika memiliki kekhususan yang sama.

Beberapa orang mengatakan bahwa kemampuan untuk membuat loop (atau bahkan loop timbal balik terbalik ganda) adalah cacat desain, tetapi untuk mencegah loop menjadi mungkin, Anda perlu membatasi kekuatan EQCSS dengan cara yang akan menghapus sebagian besar nilai yang disediakan sintaks. Di sisi lain, membuat loop tak terbatas dalam JavaScript sangat mudah, tetapi itu tidak dipandang sebagai cacat bahasa — ini dilihat sebagai bukti kekuatannya! Ini sama dengan kueri elemen.

Kueri Elemen Debug

Saat ini, kueri elemen debug dapat terasa seperti men-debug kueri media sebelum kami memiliki alat seperti inspektur web untuk menunjukkan kepada kami gaya saat dihitung pada halaman. Untuk saat ini, debugging dan pengembangan kueri elemen mengharuskan pengembang untuk mempertahankan model mental tentang perilaku responsif apa yang seharusnya terjadi. Di masa depan, membangun alat pengembang yang sadar EQCSS mungkin dilakukan, tetapi untuk saat ini, alat pengembang di semua browser utama hanya mengetahui gaya yang telah diterapkan EQCSS ke elemen pada halaman, dan mereka tidak menyadarinya. kondisi responsif yang ditonton EQCSS.

Bagaimana Mendesain Dengan Elemen Query

Cara paling sederhana untuk menggunakan kueri elemen adalah dengan mengonversi desain yang ada menggunakan kueri media menjadi kueri elemen, elemen "pembebasan" dan gaya responsifnya dari satu tata letak dan memudahkan penggunaan kembali kode itu di halaman dan proyek lain. Kueri media dan kueri elemen berikut dapat memiliki arti yang sama:

 footer a { display: inline-block; } @media (max‐width: 500px) { footer a { display: block; } }

 footer a { display: inline-block; } @element 'footer' and (max‐width: 500px) { $this a { display: block; } }

Perbedaannya adalah, dalam contoh asli, tautan footer tetap sebagai display: block hingga lebar peramban setidaknya 500 piksel. Contoh kedua, menggunakan kueri elemen, akan terlihat sama tetapi hanya jika elemen footer memiliki lebar penuh.

Setelah membebaskan gaya ini dari kueri media aslinya, sekarang kita dapat menempatkan footer dalam wadah dengan lebar berapa pun dan memastikan bahwa ketika footer membutuhkan gaya responsif untuk diterapkan (yaitu ketika lebih kecil dari 500 piksel), itu akan menjadi terapan.

1. Pastikan bahwa EQCSS.js ada di HTML dokumen tujuan.
2. Ganti @media dengan @element di CSS.
3. Tambahkan pemilih CSS ke cakupan setiap kueri @element .
4. Opsional: Ganti kemunculan elemen cakupan dengan $this dalam kueri elemen.

Kecuali jika komponen desain yang Anda konversi awalnya dirancang untuk ditampilkan menggunakan lebar penuh viewport browser, Anda mungkin harus mengubah breakpoint setelah mengonversi ke kueri elemen.

Menghindari Lock-In

Pengalaman menulis gaya EQCSS mirip dengan pengalaman menulis CSS biasa: Semua properti dan teknik CSS favorit Anda masih ada, hanya dengan beberapa fitur tambahan yang membantu mereka bekerja sama dengan cara baru. Karena EQCSS mengeluarkan CSS standar ke browser, semua fitur CSS yang didukung oleh browser Anda akan berfungsi saat digunakan dengan EQCSS. Jika suatu hari nanti fitur seperti kueri elemen dan gaya cakupan ditentukan dalam CSS dan didukung di browser, maka Anda akan dapat mulai menggunakannya dalam kode EQCSS Anda segera, sambil tetap mengandalkan EQCSS untuk fitur lain yang tidak browser namun mendukung secara asli.

Karena Anda dapat menggunakan sintaks EQCSS baik secara langsung di CSS maupun dalam skripnya sendiri, dengan tipe text/eqcss , jika CSS pernah mengembangkan sintaks untuk kueri elemen asli, Anda masih dapat memuat EQCSS sebagai skrip dan menghindari konflik .

Ke depan, salah satu solusi yang sedang bereksperimen dengan pengembang browser saat ini adalah Houdini, yang akan membuka akses bagi pengembang plugin untuk memperluas CSS dengan cara baru, seperti menambahkan dukungan ke browser itu sendiri. Suatu hari, mungkin saja untuk menulis plugin yang lebih efisien yang menginterpretasikan sintaks EQCSS dan membawa fitur-fitur ini ke browser dengan cara yang lebih langsung dan berkinerja daripada yang diizinkan oleh pustaka JavaScript saat ini.

Jadi, Haruskah Kita Masih Menggunakan Media Query?

Ya, meskipun kueri elemen menyediakan banyak cara baru dan menarik untuk menargetkan elemen dengan gaya, kueri media (meskipun terbatas) akan selalu berjalan lebih cepat di browser daripada gaya yang mengandalkan JavaScript untuk menghitung. Namun, kueri media CSS lebih dari sekadar menata HTML untuk layar. Kueri media CSS juga mendukung kueri berbasis cetak dan cara lain situs web menampilkan informasi. EQCSS dapat digunakan bersama dengan kueri media untuk hal-hal seperti gaya cetak, jadi tidak perlu menghentikan kueri media hanya karena kueri elemen sekarang juga dapat digunakan!

Merancang Dengan ²⁰ ₂₀ Visi

Hal terbaik yang dapat kita lakukan untuk masa depan CSS adalah bereksperimen dengan ide-ide ini sebanyak mungkin hari ini. Tidak ada curah pendapat dan teori tentang fitur-fitur ini yang akan berguna seperti benar-benar mencoba menerapkannya dan menggunakannya, menemukan teknik yang membuatnya berguna dan kuat.

Selain memberikan solusi untuk pertanyaan elemen, EQCSS.js diharapkan juga berfungsi sebagai platform untuk eksperimen lain dalam memperluas CSS. If you have an idea for a new responsive condition, a new CSS property or a new selector to use in your code, forking EQCSS.js and modifying it to include your idea can get you most of the way there with little effort.

Modular Design

In designing layouts using element queries, the biggest shift is learning how to stop viewing the DOM from the top down and from the perspective of only the root HTML element, and to start thinking about individual elements on the page from their own perspectives within the document.

The old paradigms of “desktop-first” and “mobile-first” responsive design aren't relevant any longer — the new way of building layouts approaches design “element-first.” Using element queries enables you to work on the individual parts that make up a layout, in isolation from one another, styling them to a greater level of detail. If you are using a modular approach for your back-end code already but have so far been unable to package your CSS with your modules because of the difficulties of styling with media queries alone, then element queries will finally allow you to modularize your styles in the same way.

Thinking Element-First

Element-first design is in the same spirit as the atomic design principle but looks different in practice from how most people have implemented atomic design in the past.

For example, let's say you have some HTML like the following, and the desired responsive behavior can be explained as, “The search input and button are displayed side by side until the form gets too narrow. Then, both the input and the button should be stacked on top of each other and displayed full width.”

 <form> <input type=search> <input type=button value=Search> </form>

Desktop-First Approach

In a desktop-first mindset, you would write styles for the desktop layout first and then add responsive support for smaller screens.

 input { width: 50%; float: left; } @media (max‐width: 600px) { input { width: 100%; float: none; } }

Mobile-First Approach

In a mobile-first mindset, you would design the mobile view first and add support for the side-by-side view only when the screen is wide enough.

 input { width: 100%; } @media (min‐width: 600px) { input { width: 50%; float: left; } }

Element-First Approach

In the first two examples, the media breakpoint was set to 600 pixels, and not because that's how wide the inputs will be when they switch. Chances are, the search input is probably inside at least one parent element that would have margins or padding. So, when the browser is 600 pixels wide, those inputs might be somewhere around 550 or 525 pixels wide on the page. In a desktop-first or mobile-first approach, you're always setting breakpoints based on the layout and how elements show up within it. With an element-first layout, you're saying, “I don't care how wide the browser is. I know that the sweet spot for where I want the inputs to stack is somewhere around 530 pixels wide.” Instead of using a media query to swap that CSS based on the browser's dimensions, with element-first design, we would scope our responsive style to the form element itself, writing a style like this:

 input { width: 100% } @element 'form' and (min‐width: 530px) { $this input { width: 50%; float: left; } }

The code is similar to that of the two previous methods, but now we are free to display this search input anywhere — in a sidebar or full width. We can use it in any layout on any website, and no matter how wide the browser is, when the form itself doesn't have enough room to display the inputs side by side, it will adapt to look its best.

Resources For Getting Started

EQCSS-Enabled Template

 <!DOCTYPE html> <html> <head> <meta charset="utf‐8"> <title></title> <style></style> </head> <body> <!‐‐[if lt IE 9]><script src="https://elementqueries.com/EQCSS‐polyfills.min.js"></script><![endif]‐‐> <script src="https://elementqueries.com/EQCSS.min.js"></script> </body> </html>

Demos

• Responsive Aspect Ratio
• Sticky Scroll Header
• Blockquote Style
• Kalender
• Content Demo
• Counting Children Demo
• Date Demo
• Zastrow-style Element Query Demo Demo
• Flyout Demo
• Headline Demo
• Media Player Demo
• Message Style Demo
• Modal Demo
• Nav Demo
• Parent Selector Demo
• Pricing Chart Demo
• Responsive Tables Demo
• Scroll-triggered Blocker Demo
• Signup Form Demo
• Testimonials Block Demo
• Tweet-Counter Demo
• JS Variables Demo
• Responsive Scaling Demo
• Geometric Design Demo
• Responsive Order Form
• Element Query Grid
• JS Functions in CSS
• Responsive Content Waterfall

Bacaan lebih lanjut

You can find the EQCSS project on GitHub, demos, documentation and articles on the EQCSS website. An ever-growing number of Codepens use EQCSS, and you can create your own pen by forking the batteries-included template that comes hooked up with EQCSS. You can also play with the EQCSS tool that I built to preview if your EQCSS code is working as expected.

Happy hacking!