Houdini: Mungkin Perkembangan Paling Menyenangkan di CSS yang Belum Pernah Anda Dengar

Pernahkah Anda ingin menggunakan fitur CSS tertentu tetapi tidak jadi karena tidak sepenuhnya didukung di semua browser ? Atau, lebih buruk lagi, itu didukung di semua browser, tetapi dukungannya bermasalah, tidak konsisten, atau bahkan sama sekali tidak kompatibel? Jika ini terjadi pada Anda — dan saya yakin itu — maka Anda harus peduli dengan Houdini.

Houdini adalah gugus tugas W3C baru yang tujuan utamanya adalah membuat masalah ini hilang selamanya. Ia berencana untuk melakukannya dengan memperkenalkan satu set API baru yang akan, untuk pertama kalinya, memberi pengembang kekuatan untuk memperluas CSS itu sendiri, dan alat untuk menghubungkan ke dalam proses penataan gaya dan tata letak mesin rendering browser .

Bacaan Lebih Lanjut tentang SmashingMag:

• Mengapa Anda Harus Berhenti Menginstal Lingkungan WebDev Anda Secara Lokal
• Masa Depan CSS: Properti CSS Eksperimental
• 53 Teknik CSS Anda Tidak Bisa Hidup Tanpanya

Tapi apa artinya, khususnya? Apakah itu ide yang bagus? Dan bagaimana ini akan membantu kami para pengembang membangun situs web sekarang dan di masa depan?

Pada artikel ini, saya akan mencoba menjawab pertanyaan-pertanyaan tersebut. Tetapi sebelum saya melakukannya, penting untuk memperjelas apa masalahnya saat ini dan mengapa ada kebutuhan untuk perubahan. Saya kemudian akan berbicara lebih khusus tentang bagaimana Houdini akan memecahkan masalah ini dan daftar beberapa fitur yang lebih menarik saat ini dalam pengembangan. Terakhir, saya akan menawarkan beberapa hal nyata yang dapat kami lakukan sebagai pengembang web hari ini untuk membantu mewujudkan Houdini.

Masalah apa yang coba dipecahkan oleh Houdini?

Setiap kali saya menulis artikel atau membuat demo memamerkan beberapa fitur CSS baru, pasti seseorang di komentar atau di Twitter akan mengatakan sesuatu seperti, “Ini luar biasa! Sayang sekali kami tidak akan dapat menggunakannya selama 10 tahun lagi. ”

Meskipun komentar seperti ini menjengkelkan dan tidak konstruktif, saya mengerti perasaan itu. Secara historis, butuh waktu bertahun-tahun bagi proposal fitur untuk diadopsi secara luas. Dan alasannya adalah, sepanjang sejarah web, satu-satunya cara untuk menambahkan fitur baru ke CSS adalah melalui proses standar.

Meskipun saya sama sekali tidak menentang proses standar, tidak dapat disangkal bahwa itu bisa memakan waktu lama!

Misalnya, flexbox pertama kali diusulkan pada tahun 2009, dan pengembang masih mengeluh bahwa mereka tidak dapat menggunakannya hari ini karena kurangnya dukungan browser. Memang, masalah ini perlahan-lahan akan hilang karena hampir semua browser modern sekarang diperbarui secara otomatis; tetapi bahkan dengan browser modern, akan selalu ada jeda antara proposal dan ketersediaan fitur secara umum.

Menariknya, ini tidak terjadi di semua area web. Pertimbangkan bagaimana hal-hal telah bekerja baru-baru ini di JavaScript:

Dalam skenario ini, waktu antara memiliki ide dan menggunakannya dalam produksi terkadang bisa menjadi hitungan hari. Maksud saya, saya sudah menggunakan fungsi async / await dalam produksi, dan fitur itu belum diimplementasikan bahkan di satu browser pun!

Anda juga dapat melihat perbedaan besar dalam sentimen umum dari kedua komunitas ini. Di komunitas JavaScript, Anda membaca artikel di mana orang mengeluh bahwa segala sesuatunya bergerak terlalu cepat. Di CSS, di sisi lain, Anda mendengar orang mengeluhkan kesia-siaan mempelajari sesuatu yang baru karena berapa lama sebelum mereka benar-benar dapat menggunakannya.

Jadi, Mengapa Kita Tidak Menulis Lebih Banyak Polyfill CSS?

Pada pemikiran pertama, menulis lebih banyak polyfill CSS mungkin tampak seperti jawabannya. Dengan polyfill yang baik, CSS dapat bergerak secepat JavaScript, bukan?

Sayangnya, tidak sesederhana itu. Polyfilling CSS sangat sulit dan, dalam banyak kasus, tidak mungkin dilakukan dengan cara yang tidak sepenuhnya merusak kinerja.

JavaScript adalah bahasa dinamis, yang berarti Anda dapat menggunakan JavaScript untuk polyfill JavaScript. Dan karena sangat dinamis, sangat dapat diperluas. CSS, di sisi lain, jarang dapat digunakan untuk polyfill CSS. Dalam beberapa kasus, Anda dapat mengubah CSS ke CSS dalam langkah pembuatan (PostCSS melakukan ini); tetapi jika Anda ingin melakukan polyfill apa pun yang bergantung pada struktur DOM atau pada tata letak atau posisi elemen, maka Anda harus menjalankan sisi klien logika polyfill Anda.

Sayangnya, browser tidak membuat ini mudah.

Bagan di bawah ini memberikan garis besar dasar tentang bagaimana browser Anda beralih dari menerima dokumen HTML hingga menampilkan piksel di layar. Langkah-langkah yang diwarnai dengan warna biru menunjukkan di mana JavaScript memiliki kekuatan untuk mengontrol hasil:

Gambarnya cukup suram. Sebagai pengembang, Anda tidak memiliki kendali atas bagaimana browser mem-parsing HTML dan CSS dan mengubahnya menjadi model objek DOM dan CSS (CSSOM). Anda tidak memiliki kendali atas kaskade. Anda tidak memiliki kendali atas bagaimana browser memilih untuk meletakkan elemen di DOM atau bagaimana ia melukis elemen tersebut secara visual di layar. Dan Anda tidak memiliki kendali atas apa yang dilakukan komposer.

Satu-satunya bagian dari proses yang Anda miliki akses penuhnya adalah DOM. CSSOM agak terbuka; namun, mengutip situs web Houdini, "tidak ditentukan, tidak konsisten di seluruh browser, dan tidak memiliki fitur penting."

Misalnya, CSSOM di browser hari ini tidak akan menampilkan aturan untuk lembar gaya lintas-asal, dan itu hanya akan membuang aturan atau deklarasi CSS yang tidak dipahami, yang berarti bahwa jika Anda ingin polifill fitur di browser yang tidak mendukungnya, Anda tidak dapat menggunakan CSSOM. Sebagai gantinya, Anda harus melalui DOM, menemukan <style> dan/atau <link rel=“stylesheet”> , mendapatkan CSS sendiri, menguraikannya, menulis ulang, lalu menambahkannya kembali ke DOM.

Tentu saja, memperbarui DOM biasanya berarti bahwa browser harus melalui seluruh langkah kaskade, tata letak, pengecatan, dan komposit lagi.

Meskipun harus merender ulang halaman sepenuhnya mungkin tidak tampak seperti pencapaian kinerja yang besar (terutama untuk beberapa situs web), pertimbangkan seberapa sering hal ini berpotensi terjadi. Jika logika polyfill Anda perlu dijalankan sebagai respons terhadap hal-hal seperti peristiwa gulir, pengubahan ukuran jendela, gerakan mouse, peristiwa keyboard — benar-benar kapan saja ada perubahan apa pun — maka semuanya akan terasa, kadang-kadang bahkan melumpuhkan, lambat.

Ini menjadi lebih buruk ketika Anda menyadari bahwa sebagian besar polyfill CSS di luar sana saat ini menyertakan parser CSS mereka sendiri dan logika kaskade mereka sendiri. Dan karena penguraian dan kaskade sebenarnya adalah hal yang sangat rumit, polifill ini biasanya terlalu besar atau terlalu buggy.

Untuk meringkas semua yang baru saja saya katakan dengan lebih ringkas: Jika Anda ingin browser melakukan sesuatu yang berbeda dari yang seharusnya dilakukan (mengingat CSS yang Anda berikan), maka Anda harus mencari cara untuk memalsukannya dengan memperbarui dan memodifikasi DOM sendiri. Anda tidak memiliki akses ke langkah-langkah lain dalam pipa rendering.

Tapi Mengapa Saya Ingin Memodifikasi Mesin Rendering Internal Peramban?

Ini, bagi saya, adalah pertanyaan yang paling penting untuk dijawab di seluruh artikel ini. Jadi, jika Anda sejauh ini membaca sekilas, bacalah bagian ini dengan perlahan dan hati-hati!

Setelah melihat bagian terakhir, saya yakin beberapa dari Anda berpikir, “Saya tidak membutuhkan ini! Saya hanya membuat halaman web biasa. Saya tidak mencoba meretas ke internal browser atau membangun sesuatu yang super mewah, eksperimental, atau mutakhir.”

Jika Anda berpikir demikian, saya sangat mendorong Anda untuk mundur sejenak dan benar-benar memeriksa teknologi yang telah Anda gunakan untuk membangun situs web selama bertahun-tahun. Menginginkan akses dan mengaitkan ke dalam proses penataan gaya browser bukan hanya tentang membuat demo mewah — ini tentang memberi pengembang dan pembuat kerangka kerja kekuatan untuk melakukan dua hal utama:

• untuk menormalkan perbedaan lintas-browser,
• untuk menciptakan atau melakukan polifill fitur baru sehingga orang dapat menggunakannya saat ini.

Jika Anda pernah menggunakan pustaka JavaScript seperti jQuery, maka Anda sudah mendapat manfaat dari kemampuan ini! Faktanya, ini adalah salah satu nilai jual utama dari hampir semua perpustakaan dan kerangka kerja front-end saat ini. Lima repositori JavaScript dan DOM paling populer di GitHub — AngularJS, D3, jQuery, React, dan Ember — semuanya melakukan banyak pekerjaan untuk menormalkan perbedaan lintas-browser sehingga Anda tidak perlu memikirkannya. Masing-masing memperlihatkan satu API, dan itu hanya berfungsi.

Sekarang, pikirkan tentang CSS dan semua masalah lintas browsernya. Bahkan kerangka kerja CSS populer seperti Bootstrap dan Foundation yang mengklaim kompatibilitas lintas-browser tidak benar-benar menormalkan bug lintas-browser — mereka hanya menghindarinya. Dan bug lintas-browser di CSS bukan hanya masa lalu. Bahkan saat ini, dengan modul tata letak baru seperti flexbox, kami menghadapi banyak ketidaksesuaian lintas-browser.

Intinya adalah, bayangkan betapa jauh lebih baik kehidupan pengembangan Anda jika Anda dapat menggunakan properti CSS apa pun dan tahu pasti itu akan berfungsi, persis sama, di setiap browser. Dan pikirkan tentang semua fitur baru yang Anda baca di entri blog atau dengar di konferensi dan pertemuan — hal-hal seperti kisi CSS, titik jepret CSS, dan penentuan posisi tetap. Bayangkan jika Anda dapat menggunakan semuanya hari ini dan dengan performa yang sama seperti fitur CSS asli. Dan yang perlu Anda lakukan hanyalah mengambil kode dari GitHub.

Ini adalah mimpi Houdini. Ini adalah masa depan yang coba diwujudkan oleh gugus tugas.

Jadi, bahkan jika Anda tidak pernah berencana untuk menulis polyfill CSS atau mengembangkan fitur eksperimental, Anda mungkin ingin orang lain dapat melakukannya — karena setelah polyfill ini ada, semua orang mendapat manfaat darinya.

Fitur Houdini Apa yang Saat Ini Sedang Dalam Pengembangan?

Saya sebutkan di atas bahwa pengembang memiliki sangat sedikit titik akses ke dalam pipa rendering browser. Sungguh, satu-satunya tempat adalah DOM dan, sampai batas tertentu, CSSOM.

Untuk mengatasi masalah ini, gugus tugas Houdini telah memperkenalkan beberapa spesifikasi baru yang akan, untuk pertama kalinya, memberikan pengembang akses ke bagian lain dari pipa rendering. Bagan di bawah ini menunjukkan alur dan spesifikasi baru mana yang dapat digunakan untuk memodifikasi langkah mana. (Perhatikan bahwa spesifikasi dalam warna abu-abu direncanakan tetapi belum ditulis.)

Beberapa bagian berikutnya memberikan gambaran singkat tentang setiap spesifikasi baru dan jenis kemampuan apa yang ditawarkannya. Saya juga harus mencatat bahwa spesifikasi lain tidak disebutkan dalam artikel ini; untuk daftar lengkapnya, lihat repositori GitHub dari draft Houdini.

API Pengurai CSS

CSS Parser API saat ini tidak ditulis; jadi, banyak dari apa yang saya katakan dapat dengan mudah berubah, tetapi ide dasarnya adalah memungkinkan pengembang untuk memperluas parser CSS dan menceritakannya tentang konstruksi baru — misalnya, aturan media baru, kelas semu baru, bersarang, @extends , @apply , dll.

Setelah parser mengetahui tentang konstruksi baru ini, parser dapat menempatkannya di tempat yang tepat di CSSOM, bukan hanya membuangnya.

API Properti dan Nilai CSS

CSS sudah memiliki properti khusus, dan, seperti yang telah saya ungkapkan sebelumnya, saya sangat senang dengan kemungkinan yang mereka buka. CSS Properties and Values ​​API membawa properti kustom selangkah lebih maju dan membuatnya lebih berguna dengan menambahkan tipe.

Ada banyak hal hebat tentang menambahkan tipe ke properti kustom, tapi mungkin nilai jual terbesarnya adalah tipe akan memungkinkan pengembang untuk melakukan transisi dan menganimasikan properti kustom, sesuatu yang tidak bisa kita lakukan hari ini.

Pertimbangkan contoh ini:

 body { --primary-theme-color: tomato; transition: --primary-theme-color 1s ease-in-out; } body.night-theme { --primary-theme-color: darkred; }

Pada kode di atas, jika kelas night-theme ditambahkan ke elemen <body> , maka setiap elemen pada halaman yang mereferensikan nilai –primary-theme-color perlahan akan bertransisi dari tomato ke darkred . Jika Anda ingin melakukannya hari ini, Anda harus menulis transisi untuk setiap elemen ini secara manual, karena Anda tidak dapat mentransisikan properti itu sendiri.

Fitur lain yang menjanjikan dari API ini adalah kemampuan untuk mendaftarkan "apply hook", yang memberi pengembang cara untuk mengubah nilai akhir dari properti kustom pada elemen setelah langkah kaskade selesai, yang bisa menjadi fitur yang sangat berguna untuk polyfill.

CSS Diketik OM

CSS Typed OM dapat dianggap sebagai versi 2 dari CSSOM saat ini. Tujuannya adalah untuk memecahkan banyak masalah dengan model saat ini dan menyertakan fitur yang ditambahkan oleh API Parsing CSS baru dan API Properti dan Nilai CSS.

Tujuan utama lainnya dari Typed OM adalah untuk meningkatkan kinerja. Mengubah nilai string CSSOM saat ini menjadi representasi JavaScript yang diketik secara bermakna akan menghasilkan peningkatan kinerja yang substansial.

API Tata Letak CSS

CSS Layout API memungkinkan pengembang untuk menulis modul tata letak mereka sendiri. Dan dengan "modul tata letak," maksud saya apa pun yang dapat diteruskan ke properti display CSS. Ini akan memberi pengembang, untuk pertama kalinya, cara untuk tata letak yang berkinerja sama seperti modul tata letak asli seperti display: flex dan display: table .

Sebagai contoh kasus penggunaan, pustaka tata letak Masonry menunjukkan sejauh mana pengembang bersedia pergi hari ini untuk mencapai tata letak kompleks yang tidak mungkin dilakukan dengan CSS saja. Meskipun tata letak ini mengesankan, sayangnya, mereka mengalami masalah kinerja, terutama pada perangkat yang kurang kuat.

CSS Layout API bekerja dengan memberi pengembang metode registerLayout yang menerima nama tata letak (yang kemudian digunakan dalam CSS) dan kelas JavaScript yang menyertakan semua logika tata letak. Berikut adalah contoh dasar bagaimana Anda dapat mendefinisikan masonry melalui registerLayout :

 registerLayout('masonry', class { static get inputProperties() { return ['width', 'height'] } static get childrenInputProperties() { return ['x', 'y', 'position'] } layout(children, constraintSpace, styleMap, breakToken) { // Layout logic goes here. } }

Jika tidak ada dalam contoh di atas yang masuk akal bagi Anda, jangan khawatir. Hal utama yang harus diperhatikan adalah kode pada contoh berikutnya. Setelah Anda mengunduh file masonry.js dan menambahkannya ke situs web Anda, Anda dapat menulis CSS seperti ini dan semuanya akan berfungsi:

 body { display: layout('masonry'); }

API Cat CSS

CSS Paint API sangat mirip dengan Layout API di atas. Ini menyediakan metode registerPaint yang beroperasi seperti metode registerLayout . Pengembang kemudian dapat menggunakan fungsi paint() di CSS di mana pun gambar CSS diharapkan dan meneruskan nama yang didaftarkan.

Berikut adalah contoh sederhana yang melukis lingkaran berwarna:

 registerPaint('circle', class { static get inputProperties() { return ['--circle-color']; } paint(ctx, geom, properties) { // Change the fill color. const color = properties.get('--circle-color'); ctx.fillStyle = color; // Determine the center point and radius. const x = geom.width / 2; const y = geom.height / 2; const radius = Math.min(x, y); // Draw the circle \o/ ctx.beginPath(); ctx.arc(x, y, radius, 0, 2 * Math.PI, false); ctx.fill(); } });

Dan itu dapat digunakan dalam CSS seperti ini:

 .bubble { --circle-color: blue; background-image: paint('circle'); }

Sekarang, elemen .bubble akan ditampilkan dengan lingkaran biru sebagai latar belakang. Lingkaran akan berada di tengah dan berukuran sama dengan elemen itu sendiri, apa pun yang terjadi.

Worklet

Banyak spesifikasi yang tercantum di atas menunjukkan contoh kode (misalnya, registerLayout dan registerPaint ). Jika Anda bertanya-tanya di mana Anda akan meletakkan kode itu, jawabannya ada di skrip worklet.

Worklet mirip dengan web worker, dan memungkinkan Anda untuk mengimpor file skrip dan menjalankan kode JavaScript yang (1) dapat dipanggil di berbagai titik dalam pipa rendering dan (2) tidak bergantung pada utas utama.

Skrip worklet akan sangat membatasi jenis operasi yang dapat Anda lakukan, yang merupakan kunci untuk memastikan kinerja tinggi.

Pengguliran dan Animasi Gabungan

Meskipun belum ada spesifikasi resmi untuk pengguliran dan animasi gabungan, ini sebenarnya adalah salah satu fitur Houdini yang lebih terkenal dan sangat dinanti. API akhirnya akan memungkinkan pengembang untuk menjalankan logika di worklet compositor, di luar utas utama, dengan dukungan untuk modifikasi subset terbatas dari properti elemen DOM. Subset ini hanya akan menyertakan properti yang dapat dibaca atau disetel tanpa memaksa mesin rendering untuk menghitung ulang tata letak atau gaya (misalnya, transformasi, opasitas, offset gulir).

Ini akan memungkinkan pengembang untuk membuat animasi berbasis gulir dan input yang berkinerja tinggi, seperti header gulir lengket dan efek paralaks. Anda dapat membaca lebih lanjut tentang kasus penggunaan yang coba diselesaikan oleh API ini di GitHub.

Meskipun belum ada spesifikasi resmi, pengembangan eksperimental telah dimulai di Chrome. Faktanya, tim Chrome saat ini mengimplementasikan titik jepret CSS dan pemosisian tetap menggunakan primitif yang nantinya akan diekspos oleh API ini. Ini luar biasa karena itu berarti API Houdini cukup berkinerja sehingga fitur Chrome baru sedang dibangun di atasnya. Jika Anda masih memiliki ketakutan bahwa Houdini tidak akan secepat penduduk asli, fakta ini saja akan meyakinkan Anda sebaliknya.

Untuk melihat contoh nyata, Surma merekam video demo yang berjalan di build internal Chrome. Demo ini meniru perilaku scroll header yang terlihat di aplikasi seluler asli Twitter. Untuk melihat cara kerjanya, lihat kode sumbernya.

Apa yang Dapat Anda Lakukan Sekarang?

Seperti yang disebutkan, saya pikir setiap orang yang membuat situs web harus peduli dengan Houdini; itu akan membuat semua hidup kita lebih mudah di masa depan. Bahkan jika Anda tidak pernah menggunakan spesifikasi Houdini secara langsung, Anda hampir pasti akan menggunakan sesuatu yang dibangun di atasnya.

Dan sementara masa depan ini mungkin tidak segera, itu mungkin lebih dekat daripada yang kita pikirkan. Perwakilan dari semua vendor browser utama menghadiri pertemuan tatap muka terakhir Houdini di Sydney awal tahun ini, dan hanya ada sedikit ketidaksepakatan tentang apa yang harus dibuat atau bagaimana melanjutkannya.

Dari apa yang saya tahu, ini bukan pertanyaan apakah Houdini akan menjadi sesuatu, tetapi kapan, dan di situlah Anda semua masuk.

Vendor browser, seperti semua orang yang membuat perangkat lunak, harus memprioritaskan fitur baru. Dan prioritas itu sering kali merupakan fungsi dari seberapa besar keinginan pengguna terhadap fitur tersebut.

Jadi, jika Anda peduli dengan ekstensibilitas gaya dan tata letak di web, dan jika Anda ingin hidup di dunia di mana Anda dapat menggunakan fitur CSS baru tanpa harus menunggunya melalui proses standar, bicarakan dengan anggota tim hubungan pengembang untuk browser yang Anda gunakan, dan beri tahu mereka bahwa Anda menginginkan ini.

Cara lain yang dapat Anda bantu adalah dengan menyediakan kasus penggunaan di dunia nyata — hal-hal yang ingin Anda dapat lakukan dengan gaya dan tata letak yang sulit atau tidak mungkin dilakukan hari ini. Beberapa draf di GitHub memiliki dokumen kasus penggunaan, dan Anda dapat mengirimkan permintaan tarik untuk menyumbangkan ide Anda. Jika dokumen tidak ada, Anda dapat memulainya.

Anggota gugus tugas Houdini (dan W3C pada umumnya) sangat menginginkan masukan yang bijaksana dari pengembang web. Kebanyakan orang yang berpartisipasi dalam proses penulisan spesifikasi adalah insinyur yang bekerja di browser. Mereka sendiri seringkali bukan pengembang web profesional, yang berarti mereka tidak selalu tahu di mana letak kelemahannya.

Mereka bergantung pada kita untuk memberitahu mereka.

Sumber Daya dan Tautan

• CSS-TAG Houdini Editor Draft, W3C Versi publik terbaru dari semua draft Houdini
• Spesifikasi Gugus Tugas Houdini CSS-TAG, GitHub Repositori Github resmi tempat pembaruan dan pengembangan spesifikasi berlangsung
• Contoh Houdini, contoh Kode GitHub yang menampilkan dan bereksperimen dengan kemungkinan API
• Milis Houdini, W3C Tempat untuk mengajukan pertanyaan umum

Terima kasih khusus kepada anggota Houdini Ian Kilpatrick dan Shane Stephens untuk meninjau artikel ini.