Miriam Suzanne adalah seorang penulis, seniman, dan developer web di Denver, Colorado, dan saat ini sedang mengerjakan spesifikasi CSS yang menarik, seperti Kueri Container dan Cascade Layers.
Postingan ini adalah bagian dari Designcember. Perayaan desain web, dipersembahkan oleh web.dev.
Miriam Suzanne adalah seorang penulis, seniman, dan developer web di Denver, Colorado. Ia adalah co-founder OddBird (agensi web), staf penulis untuk CSS Tricks, anggota tim inti Sass, dan Pakar yang Diundang W3C di CSS Working Group. Akhir-akhir ini, ia berfokus pada pengembangan fitur CSS baru seperti Lapisan Bertingkat, Kueri Penampung, dan Cakupan. Secara offline, Miriam adalah seorang novelis, penulis drama, dan musisi yang telah diterbitkan. Kami berbicara tentang pekerjaannya dengan Sass dan CSS.
Rachel: Saya pertama kali mempelajari pekerjaan Anda karena adanya framework petak 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 (tapi masih rumit). Terdapat peningkatan dalam "framework grid" 12 kolom satu ukuran untuk semua, yang menyediakan petak yang telah ditentukan (biasanya statis) dengan serangkaian class CSS yang telah ditentukan sebelumnya. Jika Anda membutuhkan sesuatu yang lebih dapat disesuaikan, Anda sendiri yang melakukannya. Jelas bahwa situs web perlu menjadi lebih responsif, tetapi kueri media belum tersedia, dan ada banyak masalah kompatibilitas browser seputar {i>flood float<i}.
Saya menggunakan pendekatan Sistem CSS Natalie Downe, yang cerdas dalam merespons ukuran font dan area pandang, tetapi saya merasa frustrasi dengan semua retasan browser dan matematika berulang yang diperlukan. Pada saat yang sama, Sass mulai mendapatkan perhatian, dan itu sangat cocok dengan yang saya butuhkan. Draf pertama Susy sangatlah sederhana: cukup beberapa mixin untuk menghitung dan menambahkan tips yang saya perlukan. Tujuannya adalah menjadi minimal, dan hanya menghasilkan kode penting. Petak yang dapat disesuaikan sepenuhnya, tanpa class yang telah ditentukan sebelumnya.
Rachel: Bagaimana cara Anda beralih dari praprosesor CSS ke pengerjaan spesifikasi CSS? Apakah Anda pikir mengerjakan preprocessor adalah latar belakang yang baik untuk penulisan spesifikasi?
Miriam: Berdasarkan pengalaman saya, ada banyak tumpang tindih, dan saya masih sangat aktif di kedua sisi pembagian tersebut. Namun, saya rasa itu semua 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. Menggunakan solusi yang "tidak cocok untuk semua" dan membangun fleksibilitas jangka panjang sangatlah penting saat Anda memikirkan masa depan standar web inti.
Bagaimana cara membuat alat yang menghargai keberagaman kebutuhan dan pendekatan developer, sekaligus tetap mendorong dan memfasilitasi aksesibilitas serta pertimbangan penting lainnya?
Rachel: Kami memiliki banyak hal yang masuk ke CSS yang pada dasarnya menggantikan fungsi yang biasanya merupakan bagian dari Sass. Apakah ada alasan kuat untuk tetap menggunakan hal seperti Sass?
Miriam: Ya, bagi sebagian orang—tetapi tidak ada jawaban universal di sini. Misalnya variabel. Variabel Sass dicakup secara leksikal, dan dikompilasi di server, dengan struktur data terorganisir seperti daftar dan objek, manipulasi warna, dll. Itu bagus untuk logika sistem desain yang tidak perlu dijalankan di browser.
Variabel CSS memiliki beberapa tumpang tindih, mereka juga dapat menyimpan nilai, tetapi mereka memberikan serangkaian kekuatan dan kelemahan berbasis menurun yang sepenuhnya berbeda. Sass tidak dapat menangani properti khusus, dan CSS tidak dapat menangani data terstruktur. Keduanya berguna dan keduanya sangat penting—tetapi kebutuhan spesifik Anda mungkin berbeda-beda.
Saya pikir ini bagus ketika seseorang dapat menghilangkan alat yang tidak lagi mereka butuhkan, dan beberapa proyek mungkin tidak memerlukan variabel sisi server dan klien. Bagus. Namun, terlalu mudah untuk mengasumsikan bahwa keduanya identik, dan salah satunya menggantikan yang lain. Akan selalu ada kasus penggunaan untuk beberapa logika desain yang terjadi di sisi server, dan beberapa terjadi di sisi klien—bahkan jika kita sampai pada titik di mana bahasa tersebut menyediakan fitur yang pada dasarnya sama. Pra-pemroses tersedia untuk jangka panjang.
Rachel: Apakah ada sesuatu yang mengejutkan Anda karena Anda lebih terlibat dalam pekerjaan pembuatan standar, atau apa pun yang menurut Anda umum tidak diketahui oleh orang-orang tentang proses tersebut?
Miriam: Sebelum dilibatkan, proses pembuatan standardisasi terasa seperti kotak hitam misterius dan ajaib, dan saya tidak yakin apa yang diharapkan. Saya takut bahwa saya mungkin tidak memiliki pengetahuan yang memadai tentang internal browser untuk berkontribusi, tetapi kenyataannya adalah mereka tidak memerlukan lebih banyak engineer browser. Mereka membutuhkan lebih banyak pengembang dan desainer yang membangun situs web dan aplikasi di dunia nyata.
Saya terkejut menemukan bahwa sangat sedikit dari orang-orang yang terlibat yang fokus utamanya adalah standar, tetapi juga sangat sedikit dari mereka yang terutama mengembangkan atau mendesain situs web. W3C terdiri atas 'sukarelawan' dari organisasi-organisasi anggota (sering kali dibayar oleh organisasi-organisasi tersebut, tetapi bukan sebagai pekerjaan utama mereka) dan keanggotaannya tidak murah. Hal itu membuat 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 akan sepenuhnya menjadi sukarelawan, hobi yang mahal, jika saya tidak menemukan pendanaan dari luar untuk pekerjaan tersebut.
Sebenarnya, prosesnya cukup terbuka dan bersifat publik serta memerlukan keterlibatan developer–tetapi selalu ada begitu banyak percakapan yang terjadi sekaligus, mungkin sulit untuk menemukan tempat Anda. Apalagi jika itu bukan pekerjaan sehari-hari Anda.
Rachel: Kueri container telah menjadi hal penting bagi banyak developer web selama bertahun-tahun. Saya sangat senang karena kami berhasil mendapatkannya. Saya merasa seolah-olah banyak orang memikirkan kegunaan kueri container—apakah Anda merasa mereka berpotensi untuk mendorong lebih banyak kreativitas?
Miriam: Tentu saja, meskipun saya tidak melihatnya secara terpisah. Kita semua memiliki waktu yang terbatas, dan kita mencoba menulis kode yang mudah dikelola dan berperforma tinggi. Ketika sesuatu sulit dilakukan secara praktis, kita cenderung tidak kreatif dengan apa yang mungkin dilakukan.
Namun, industri web sekarang didominasi oleh kepentingan perusahaan yang besar, sehingga permasalahan bisnis tersebut selalu mendapatkan waktu tayang yang lebih banyak daripada artis web. Menurut saya, kita akan kehilangan banyak kerugian jika mengabaikan kreativitas web sebagai kasus penggunaan utama fitur. Saya sangat bersemangat untuk melihat beberapa orang seni CSS bermain dengan prototipe kueri kontainer. Jhey Tompkins membuat demo yang sangat cerdas dan interaktif dari tirai Venesia CSS sebagai komentar tentang meme anti-CSS lama. Ada begitu banyak hal yang dapat dijelajahi di bidang tersebut, dan saya tidak sabar untuk melihat ide-ide lain yang akan ditemukan pengguna.
Percakapannya juga berfokus pada kueri berbasis ukuran, sebagai kasus penggunaan aslinya, tetapi saya senang melihat apa yang dilakukan pengguna dengan kueri gaya–kemampuan untuk menulis gaya bersyarat berdasarkan nilai properti atau variabel CSS. Ini adalah fitur yang sangat canggih dan sejauh ini belum banyak dieksplorasi. Kupikir itu membuka lebih banyak peluang kreatif!
Rachel: Apakah ada sesuatu yang tidak dapat kami lakukan (atau memiliki cara mendatang untuk dilakukan) di CSS yang menurut Anda akan berguna?
Miriam: Saya sangat senang dengan beberapa spesifikasi lain yang sedang saya kerjakan. Lapisan bertingkat akan memberi penulis kontrol yang lebih besar atas masalah kekhususan, dan Cakupan akan membantu penargetan pemilih yang lebih tepat. Namun, keduanya merupakan masalah arsitektur tingkat tinggi. Seniman dalam diri saya lebih tertarik dengan hal-hal seperti tombol alih CSS, cara deklaratif untuk membuat gaya interaktif, atau 'linimasa' penampung, sehingga kita bisa melakukan transisi nilai antara titik henti sementara media atau container dengan lancar. Hal itu memiliki implikasi yang sangat praktis untuk tipografi responsif, tetapi juga akan membuka banyak peluang kreatif untuk seni dan animasi yang responsif.
Rachel: Siapa lagi yang melakukan pekerjaan yang benar-benar menarik, menyenangkan, atau kreatif di web saat ini?
Miriam: Oh, saya bahkan tidak yakin bagaimana menjawabnya, ada begitu banyak orang yang melakukan pekerjaan 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 terbesar dari seniman web, dan bagaimana orang-orang memproduksi alat ini, dengan cara yang tidak terkait langsung dengan perdagangan. Orang-orang seperti Jhey, Lynn Fisher, atau Yuan Chuan, atau banyak orang lainnya yang mendorong batasan terkait kemampuan teknologi web secara visual dan interaktif. Bahkan orang yang melakukan lebih banyak pekerjaan berbasis bisnis dapat belajar banyak dari teknik artistik mereka.
Saya juga mengapresiasi 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. Misalnya, lihat minus.social barunya.
Rachel: Ikuti terus karya Miriam terkait CSS di css.oddbird.net dan cari tahu apa lagi yang dia lakukan melalui situsnya di miriam.codes dan Twitter @TerribleMia.