Miriam Suzanne adalah seorang penulis, seniman, dan developer web di Denver, Colorado. Dia saat ini sedang mengerjakan spesifikasi CSS yang menarik seperti Container Kueri dan Cascade Layers.
Postingan ini adalah bagian dari Designcember. Perayaan desain web, yang dipersembahkan oleh web.dev.
Miriam Suzanne adalah seorang penulis, artis, dan developer web di Denver, Colorado. Dia adalah co-founder OddBird (agensi web), staf penulis untuk CSS Tricks, anggota tim inti Sass, dan W3C Diundang Expert di CSS Working Group. Akhir-akhir ini, ia berfokus pada pengembangan fitur CSS baru seperti Lapisan Cascade, Kueri Penampung, dan Cakupan. Offline, Miriam adalah seorang novelis, penulis drama, dan musisi yang sudah diterbitkan. Kita membahas tentang pekerjaannya dengan Sass dan CSS.
Rachel: Saya pertama kali mengetahui karya Anda karena framework petak Anda Susy, apa yang mendorong Anda untuk membuatnya?
Miriam: Pada tahun 2008, tata letak di web adalah pengalaman yang sangat berbeda. Developer telah beralih dari tata letak tabel ke petak float yang lebih semantik (tetapi masih tampak rumit). Ada boom dalam "kerangka kerja grid" 12 kolom yang cocok untuk semua, yang menyediakan grid yang telah ditentukan sebelumnya (biasanya statis) dengan serangkaian class CSS yang telah ditentukan sebelumnya. Jika Anda membutuhkan sesuatu yang lebih dapat disesuaikan, Anda harus melakukan sendiri. Sudah jelas bahwa {i>website<i} perlu menjadi lebih responsif, tetapi kueri media belum tersedia, dan ada banyak masalah kompatibilitas {i>browser<i} seputar float {i>float<i}.
Saya menggunakan pendekatan Sistem CSS Natalie Downe, yang pintar dalam merespons ukuran font dan area pandang, tetapi saya merasa frustrasi dengan semua perhitungan berulang dan peretasan browser yang diperlukan. Pada saat yang sama, Sass mulai mendapat perhatian, dan sangat cocok dengan apa yang saya butuhkan. Draf pertama Susy sangatlah sederhana: hanya beberapa mixin untuk melakukan perhitungan dan menambahkan trik yang saya perlukan. Tujuannya adalah agar kampanye menjadi minimal, dan hanya menampilkan kode yang penting. Petak yang sepenuhnya dapat disesuaikan, tanpa class yang telah ditentukan sebelumnya.
Rachel: Bagaimana Anda beralih dari pengerjaan praprosesor CSS ke spesifikasi CSS? Menurut Anda, apakah mengerjakan praprosesor adalah latar belakang yang baik untuk penulisan spesifikasi?
Miriam: Berdasarkan pengalaman saya, ada banyak tumpang-tindih, dan saya masih sangat aktif di kedua sisi pemisah itu. Namun, saya rasa hal itu sebagian besar berkat tim Sass, khususnya yang dipimpin oleh Natalie Weizenbaum, yang memiliki pandangan jangka panjang—mencoba mengembangkan alat yang terintegrasi secara lancar dengan pengembangan standar web. Mendorong lebih dari sekadar "berpendirian" solusi dan membangun fleksibilitas jangka panjang adalah hal penting saat Anda memikirkan masa depan standar web inti.
Bagaimana kita bisa membuat alat yang menghormati keberagaman kebutuhan dan pendekatan developer, sekaligus tetap mendorong dan memfasilitasi aksesibilitas serta pertimbangan penting lainnya?
Rachel: Kami memiliki banyak fitur yang akan hadir di CSS yang pada dasarnya menggantikan fungsi yang dulunya merupakan bagian dari Sass. Apakah ada alasan kuat untuk tetap menggunakan sesuatu seperti Sass?
Miriam: Ya, untuk sebagian orang—tetapi tidak ada jawaban universal di sini. Misalnya, variabel. Variabel Sass tercakup secara leksik, dan dikompilasi di server, dengan struktur data yang terorganisir seperti daftar dan objek, manipulasi warna, dll. Hal ini sangat bagus untuk logika sistem desain yang tidak perlu dijalankan di browser.
Variabel CSS memiliki beberapa tumpang tindih, dan juga dapat menyimpan nilai, tetapi memberikan serangkaian kekuatan dan kelemahan berbasis urutan yang benar-benar berbeda. Sass tidak dapat menangani properti khusus, dan CSS tidak benar-benar dapat menangani data terstruktur. Keduanya berguna, dan keduanya sangat kuat—tetapi kebutuhan spesifik Anda mungkin bervariasi.
Saya pikir, itu adalah hal yang bagus ketika seseorang dapat menghilangkan alat yang tidak lagi mereka perlukan, dan beberapa project mungkin tidak memerlukan variabel sisi server dan sisi klien. Bagus. Namun, terlalu mudah untuk mengasumsikan bahwa hal itu berarti identik, dan yang satu menggantikan yang lainnya. Akan selalu ada kasus penggunaan agar beberapa logika desain terjadi di sisi server, dan beberapa lainnya terjadi di sisi klien—meskipun kita sampai pada titik di mana bahasa tersebut pada dasarnya menyediakan fitur yang sama. Pra-prosesor bersama kita dalam jangka panjang.
Rachel: Apakah ada sesuatu yang mengejutkan Anda karena Anda semakin terlibat dalam pekerjaan pembuatan standar, atau hal apa pun yang menurut Anda mungkin tidak diketahui oleh masyarakat umum tentang prosesnya?
Miriam: Sebelum terlibat, proses standarnya terasa seperti kotak hitam yang misterius dan ajaib, dan saya tidak yakin apa yang diharapkan. Saya khawatir saya mungkin tidak memiliki pengetahuan yang cukup tentang bagian dalam browser untuk berkontribusi, tetapi kenyataannya mereka tidak memerlukan lebih banyak engineer browser. Mereka membutuhkan lebih banyak pengembang dan desainer yang sedang membangun {i>website<i} dan aplikasi di luar sana.
Saya terkejut mendapati bahwa sangat sedikit orang yang terlibat terutama berfokus pada standar, tetapi juga sangat sedikit dari mereka yang terutama mengembangkan atau merancang {i>website<i}. W3C terdiri dari 'sukarelawan' dari organisasi anggota (sering kali dibayar oleh organisasi tersebut, tetapi bukan sebagai pekerjaan utama mereka) dan keanggotaannya tidaklah murah. Hal tersebut membuat para peserta menjauh dari desainer dan pengembang sehari-hari, terutama mereka yang melakukan pekerjaan klien di agensi kecil, atau {i>freelance<i}. Peran saya sebagai Pakar yang Diundang adalah menjadi sukarelawan, sebuah hobi yang mahal, jika saya tidak menemukan pendanaan luar untuk pekerjaan itu.
Pada kenyataannya, prosesnya cukup terbuka dan bersifat publik serta memerlukan keterlibatan developer–tetapi selalu ada begitu banyak percakapan yang terjadi sekaligus, sehingga sulit untuk menemukan posisi Anda. Apalagi jika itu bukan pekerjaan harian Anda.
Rachel: Kueri container telah menjadi hal penting bagi banyak developer web selama bertahun-tahun. Saya sangat senang dengan fakta bahwa kami mendapatkannya. Saya merasa banyak orang memikirkan kegunaan kueri container—apakah Anda merasa mereka juga berpotensi membuka lebih banyak kreativitas?
Miriam: Tentu saja, meskipun saya tidak menganggapnya sama sekali terpisah. Kita semua memiliki waktu yang terbatas, dan saat ini kita berupaya menulis kode yang mudah dikelola dan berperforma baik. Ketika sesuatu sulit untuk dilakukan secara praktis, kita cenderung tidak kreatif dengan apa yang mungkin dilakukan.
Namun, industri web kini didominasi oleh kepentingan perusahaan yang besar, sehingga masalah bisnis tersebut selalu mendapatkan lebih banyak waktu luang daripada artis web. Dan saya pikir kita akan kehilangan banyak jika kita mengabaikan kreativitas web sebagai kasus penggunaan utama untuk fitur. Saya sangat bersemangat untuk melihat beberapa ahli seni CSS bermain dengan prototipe kueri container. Jhey Tompkins membuat demo yang sangat cerdas dan interaktif tentang kerai venetian CSS sebagai komentar terhadap meme anti-CSS lama. Saya pikir masih banyak lagi yang dapat dijelajahi di bidang tersebut, dan saya tidak sabar untuk melihat temuan orang lain.
Percakapan ini juga berfokus pada kueri berbasis ukuran, sebagai kasus penggunaan aslinya, tetapi saya ingin melihat apa yang dilakukan orang-orang dengan kueri gaya, yakni kemampuan untuk menulis gaya bersyarat berdasarkan nilai properti atau variabel CSS. Ini adalah fitur yang sangat hebat, dan sejauh ini masih belum banyak dieksplorasi. Menurut saya, hal ini membuka lebih banyak peluang kreatif.
Rachel: Apakah ada hal yang tidak dapat kami lakukan (atau akan ada cara berikutnya) di CSS yang menurut Anda akan berguna?
Miriam: Saya sangat antusias dengan beberapa spesifikasi lain yang sedang saya kerjakan. Lapisan berjenjang akan memberikan kontrol yang lebih besar kepada penulis atas masalah kekhususan, dan Cakupan akan membantu dalam penargetan pemilih yang lebih tepat. Namun, keduanya merupakan masalah arsitektur tingkat tinggi. Artis dalam diri saya lebih menyukai hal-hal seperti tombol CSS, cara deklaratif untuk membuat gaya interaktif, atau 'linimasa' container, sehingga kami dapat melakukan transisi nilai antara titik henti sementara media atau container dengan lancar. Hal tersebut memiliki implikasi yang sangat praktis untuk tipografi responsif, tetapi juga akan membuka banyak peluang kreatif untuk seni dan animasi responsif.
Rachel: Siapa lagi yang melakukan karya yang sangat menarik, menyenangkan, atau kreatif di web saat ini?
Miriam: Oh, saya bahkan tidak yakin bagaimana menjawabnya, ada begitu banyak orang yang melakukan karya kreatif di berbagai bidang. Ada banyak standar menarik yang sedang dikerjakan dari CSSWG dan Open-UI, termasuk beberapa pekerjaan Anda mengenai fragmentasi. Namun, saya sering menemukan inspirasi paling besar dari seniman web, dan bagaimana orang-orang menggunakan alat ini dalam produksi, dengan cara yang tidak terkait langsung dengan perdagangan. Orang-orang seperti Jhey atau Lynn Fisher, atau Yuan Chuan, atau banyak lainnya yang mendorong terobosan dalam kemampuan teknologi web secara visual dan interaktif. Bahkan orang yang melakukan pekerjaan yang lebih berbasis bisnis dapat belajar banyak dari teknik artistik mereka.
Saya juga menghargai karya seni web yang lebih konseptual dari orang-orang seperti Ben Grosser, yang terus mendorong kami untuk mempertimbangkan kembali apa yang kita inginkan dari web, dan khususnya media sosial. Lihat minus.social barunya, misalnya.
Rachel: Ikuti terus perkembangan Miriam terkait CSS di css.oddbird.net dan cari tahu apa lagi yang dia lakukan melalui situsnya di miriam.codes dan Twitter @TerribleMia.