Permintaan Masukan WebKit untuk Standardisasi Layout ‘Masonry’ CSS Grid Level 3

(webkit.org)

2 poin oleh GN⁺ 2024-04-24 | 1 komentar | Bagikan ke WhatsApp

WebKit meminta masukan dari desainer dan developer dalam proses menstandardisasi layout masonry/waterfall di CSS, yang sudah lama rumit, sebagai CSS Grid Level 3
Model yang diusulkan bekerja di atas display: grid dengan grid-template-rows: masonry untuk mematikan pembuatan baris, lalu mengisi ruang kosong dengan konten seperti susunan bata
Apple menilai fitur ini harus berada di dalam Grid agar dapat digabungkan dengan kemampuan Grid yang sudah ada seperti fr, minmax(), max-content, spanning, penempatan eksplisit, dan subgrid
Pendekatan display: masonry terpisah memang bisa memisahkan tipe layout dengan lebih sederhana, tetapi dalam diskusi kemungkinan akan dibatasi pada kolom dengan lebar yang sama, dan sulit memanfaatkan kemampuan pengaturan ukuran track milik Grid
Setelah pembaruan Oktober 2024, CSS Working Group menyimpulkan bahwa track dengan lebar variabel, penempatan eksplisit, spanning, dan subgrid bernilai untuk dimasukkan ke masonry serta dapat diimplementasikan dengan performa baik, tetapi diskusi sintaks masih berlanjut

Posisi CSS Grid Level 3 Saat Ini

Setelah pembaruan Oktober 2024, Working Draft resmi W3C untuk CSS Grid Layout Module Level 3 telah dibuat, dan cara kerja layout masonry telah didokumentasikan
Para anggota CSS Working Group menyimpulkan bahwa fitur berikut bernilai untuk dimasukkan ke layout masonry dan dapat diimplementasikan secara performan
- Track dengan lebar variabel
- Penempatan eksplisit
- Spanning
- subgrid
Namun perdebatan tentang sintaks masih terbuka, dan WebKit melanjutkannya dalam artikel terpisah Help us choose the syntax for Masonry in CSS

Mengapa Layout Masonry Dibutuhkan

CSS Grid Level 1 diperkenalkan pada 2017 dan mengurangi beban pengaturan ukuran serta penempatan pada layout berbasis float, sementara Grid Level 2 menyediakan Subgrid
Namun bahkan setelah CSS Grid hadir, selama 7 tahun belum ada jawaban yang jelas untuk pertanyaan “bagaimana menulis layout masonry dengan CSS”
Layout masonry adalah pola penempatan konten yang saling mengisi seperti bata atau dinding batu, dan juga disebut waterfall layout
Karena dapat menangani konten dengan rasio aspek berbeda-beda, kebutuhan untuk memotong atau mengecilkan semua item agar menjadi persegi panjang yang sama berkurang
Karena konten tersebar di seluruh halaman, urutan baca saat scrolling dapat tetap alami, dan saat menambahkan konten dengan lazy-load di bagian bawah, konten yang sudah ada tidak perlu digeser

Riwayat Usulan dan Perdebatan Standardisasi

Mekanisme untuk membuat layout masonry di CSS pertama kali diusulkan Mozilla pada Januari 2020 sebagai ekstensi CSS Grid, dan diimplementasikan sebagai fitur eksperimental di balik flag pada Firefox Nightly
Apple mulai mengimplementasikan usulan CSS Grid Level 3 di Safari Technology Preview pada 2022, dan saat ini aktif secara default
Di dalam CSS Working Group, terdapat perbedaan pendapat soal arah dasar
- Sebagian menilai masonry seharusnya menjadi tipe display terpisah, bukan bagian dari CSS Grid
- Sebagian tidak yakin apakah layout ini dibutuhkan di web dan apakah situs web terkenal akan menggunakannya
WebKit menilai bahwa agar browser dapat merilis fitur ini, konsensus CSS Working Group diperlukan terlebih dahulu

Cara Pakai Dasar: Grid yang Mematikan Baris dan Hanya Memakai Kolom

Layout masonry/waterfall klasik ditulis dengan menerapkan display: grid pada elemen main, mendefinisikan kolom, lalu menetapkan nilai masonry pada arah baris

main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
  grid-template-rows: masonry;
}

grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr)) membuat kolom fleksibel berulang dengan lebar minimum 14rem
gap: 1rem membuat jarak 1rem di antara kolom dan item
grid-template-rows: masonry memberi tahu browser untuk tidak membuat baris, melainkan mengisi konten dalam pola masonry/waterfall
Contoh ini membuat layout fleksibel yang menyesuaikan berbagai ukuran layar hanya dengan empat baris CSS, tanpa media query atau container query
Saat ini nama nilai masonry masih mungkin berubah sebelum dirilis di browser

Alasan Mempertahankan Kemampuan Grid dalam Mendefinisikan Kolom

WebKit membuat empat demo untuk menunjukkan alasan mengapa masonry harus menjadi bagian dari CSS Grid, dan dapat dicoba langsung di webkit.org/demos/grid3
Demo dapat dilihat di browser yang mendukung Grid Level 3
- Safari Technology Preview
- Firefox jika masonry grid layout feature flag diaktifkan
CSS Grid menyediakan berbagai opsi saat mendefinisikan kolom
- Ukuran tetap dalam berbagai unit seperti px, em, rem, cqi, lh, ch, ic, cap, vw, svh
- max-content, min-content
- Unit fr
- minmax()
- Ukuran %
- auto
Misalnya, kolom pertama dan terakhir dapat dibuat dengan lebar tetap 14ch, sementara kolom tengah dibuat sebagai kolom fleksibel dengan minimum 28ch

main {
  display: grid;
  grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
  grid-template-rows: masonry;
  gap: 1rem;
}

Menggabungkan unit fr dan minmax() dapat menciptakan fleksibilitas dua tahap, di mana kolom melebar dan menyusut pada tahap yang berbeda
max-content dan min-content membuat ukuran kolom menyesuaikan ukuran konten, memungkinkan penempatan yang berbeda dari pendekatan menyesuaikan konten ke kolom
Kolom dengan lebar berbeda juga dapat dibuat memakai Fibonacci sequence, seperti grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr;
Contoh mega menu menggunakan grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); agar setiap kolom cukup besar untuk memuat teks tautan tanpa line break
WebKit menilai diskusi display: masonry terpisah mengarah pada hanya mengizinkan kolom berukuran sama, seperti multicolumn layout saat ini

Spanning, View Transitions, dan Columnar Grid

CSS Grid dapat membuat item membentang melintasi beberapa kolom, sehingga memungkinkan berbagai komposisi visual dalam penempatan masonry
Dalam contoh, setiap gambar ke-5 dapat dibuat membentang dua kolom, sementara gambar lainnya hanya menempati satu kolom
Variasi lain juga memungkinkan, seperti memberi class wider pada gambar dengan rasio aspek lebih lebar agar menempati beberapa kolom, mengubah sudut menjadi persegi, atau mengurangi jarak menjadi 0
Demo Photos menggabungkannya dengan View Transitions: ketika pengguna mengklik atau mengetuk foto, foto tersebut membesar melintasi beberapa kolom dan browser menganimasikan transisinya secara otomatis
- Demo ini membutuhkan Safari Technology Preview 192 atau lebih baru
WebKit memandang inti Grid Level 3 bukan sebagai pola khusus bernama “masonry”, melainkan sebagai mekanisme untuk mematikan baris
Cara ini membuat columnar grid yang hanya tersusun dari kolom, berbeda dengan modular grid yang baris dan kolomnya sama-sama sejajar, yang dibuat dengan baik oleh CSS Grid Level 1

Perbedaan Modular Grid dan Columnar Grid

Modular grid adalah Grid yang kontennya disejajarkan pada kolom dan baris, dan CSS Grid Level 1 cocok untuk penempatan seperti ini
Layout berbasis float juga mendorong penggunaan modular grid di web, karena tinggi konten harus disamakan agar float dapat tersusun dengan benar
Di situs web nyata, sering kali rasio aspek gambar dibuat sama, panjang teks disamakan, atau konten dipaksa masuk ke kotak yang seragam melalui kebijakan CMS maupun cropping dan ellipsis dengan CSS
Columnar grid memungkinkan konten mempertahankan ukuran yang diinginkannya, sementara layout bekerja menyesuaikan konten
WebKit melihat bahwa konten berbasis teks pun dapat ditata lebih hidup melalui contoh yang membuat artikel terbaru membentang empat kolom, beberapa artikel terkini membentang dua kolom, dan konten lama ditempatkan satu kolom

Menggabungkan Subgrid dan Penempatan Eksplisit

subgrid dari CSS Grid Level 2 didukung di sebagian besar browser
Contoh halaman museum, alih-alih mencantumkan metadata kartu lukisan dalam satu kolom rata kiri, memakai subgrid untuk menempatkan tahun dan nomor katalog di sisi kanan setiap kartu serta menyelaraskannya dengan data yang sama pada kartu lain
Jika masonry masuk ke CSS Grid Level 3, developer tools yang ada juga dapat tetap dimanfaatkan
- Grid Inspector di Safari Technology Preview dapat digunakan untuk menguji grid-template-rows: masonry
Jika menjadi tipe display terpisah, manfaat subgrid tidak akan diperoleh
Penempatan eksplisit dari CSS Grid Level 1 juga dapat digunakan bersama; dalam contoh, header ditempatkan di kanan atas halaman pada dua kolom terakhir dengan grid-column: -3 / -1
WebKit menilai beberapa baris kode layout dapat menggabungkan fitur Grid Level 1, 2, dan 3 untuk membuat layout yang jumlah kolomnya berubah mengikuti ukuran yang tersedia tanpa media query atau container query

Isu dengan `display: masonry`

WebKit dan Apple memandang Masonry sebagai fitur yang memperluas CSS Grid agar dapat membuat bukan hanya modular grid, tetapi juga columnar grid
Dalam arah ini, fitur Grid seperti definisi kolom, track spanning, penempatan eksplisit, dan subgrid dapat digunakan bersama
Pihak yang lebih menyukai tipe display terpisah menilai tipe layout dapat dipisahkan dengan rapi

display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;

CSS Working Group belum mendiskusikan sintaks untuk Masonry display type terpisah, tetapi WebKit memberi contoh sintaks yang mirip Multicolumn layout atau sintaks terbatas yang menyerupai Grid

main {
  display: masonry;
  columns: 28ch;
}

main {
  display: masonry;
  masonry-columns: repeat(5, minmax(28ch, 1fr));
                   /* where only one repeating width is allowed */
}

Tipe layout terpisah dapat menghindari pekerjaan yang dibutuhkan untuk terus membuat Grid dan Masonry bekerja bersama
- Model layout menjadi lebih sederhana
- Implementasi browser menjadi lebih mudah
- Kemungkinan jebakan performa berkurang
- Set fitur Grid dan Masonry dapat berbeda satu sama lain
Sebaliknya, WebKit menilai jika kedua jenis layout Grid terhubung, CSS Working Group di masa depan akan mendefinisikan fitur untuk modular grid maupun columnar grid
Misalnya, jika CSS Grid Level 4 menambahkan fitur seperti styling grid area dan grid line, warna latar track, atau rule line pada gap, lebih baik fitur tersebut sejak awal bekerja pada kedua jenis Grid

Bagaimana Melihat “Grid”

Pihak yang mendukung display: masonry terpisah terkadang melihat CSS Grid pada dasarnya sebagai penyelarasan dua dimensi, sementara masonry hanya menyelaraskan satu arah sehingga bukan Grid
WebKit melihat bahwa dalam sejarah graphic design, grid adalah alat untuk menyelaraskan teks, gambar, dan konten ke pola teratur demi membantu keterbacaan dan kegunaan
Berbagai grid telah digunakan bahkan sebelum kaum modernis Eropa dan Amerika abad ke-20 menekankan penyelarasan pada kolom dan baris sebagai “proper” graphic design grid
Mark Boulton memandang columnar grid simetris sebagai formal dan membosankan, serta mendorong penggunaan compound grid asimetris dalam desain web
CSS Grid Level 1 memudahkan pembuatan grid asimetris dan compound grid, tetapi saat ini itu hanya berlaku ketika Grid tersebut adalah modular grid
WebKit menilai modular grid dan columnar grid sama-sama merupakan grid, dan CSS Grid juga harus punya kemampuan untuk membuat columnar grid

Masukan yang Diminta dari Developer dan Desainer

WebKit meminta developer dan desainer membuat demo sendiri, menulis pendapat di blog atau media sosial, dan meninggalkan komentar pada isu CSS Working Group
Pertanyaan yang menjadi sasaran masukan adalah sebagai berikut
- Apakah “masonry”/“waterfall” harus menjadi bagian dari CSS Grid
- Apakah fitur columnar grid yang mencakup subgrid, spanning, penempatan eksplisit, dan beragam track sizing dibutuhkan
- Apakah layout masonry klasik dengan kolom berukuran sama saja sudah cukup
- Apakah fitur ini benar-benar akan digunakan, dan apa yang bisa dibuat dengannya
- Apakah ada tautan demo yang dibuat
- Apakah ada hal yang tidak bisa dilakukan dengan model ini
Tim WebKit telah mengerjakan Masonry selama satu setengah tahun, dan fitur ini diaktifkan secara default pada Safari Technology Preview 163 pada Februari 2023
Mereka ingin segera merilis fitur ini, tetapi detail termasuk nama dan pertanyaan mendasar harus diselesaikan terlebih dahulu

Diskusi Nama: `masonry`, `waterfall`, `off`

WebKit menilai masonry kemungkinan besar bukan nama terbaik untuk nilai baru ini
Nama CSS biasanya berupa kata sederhana yang langsung menjelaskan hasilnya, seperti center, contain, clip, wrap, smooth
masonry adalah metafora yang membutuhkan penjelasan latar belakang, sehingga bisa sulit diingat oleh developer yang tidak berbahasa Inggris
Di beberapa wilayah, layout ini lebih sering disebut waterfall, sehingga grid-template-rows: waterfall juga bisa menjadi kandidat
WebKit memandang fitur ini lebih dekat ke mekanisme “buat Grid, tetapi jangan buat baris” daripada layout bergaya Pinterest itu sendiri
grid-template-rows: none; mungkin cocok secara makna, tetapi none sudah menjadi nilai default grid-template-* yang berarti “tanpa baris eksplisit, hanya minta baris implisit”, sehingga tidak dapat digunakan
Sebagai alternatif, grid-template-rows: off; diajukan

main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  grid-template-rows: off;
}

CSSWG sedang mendiskusikan nama di isu ini
Saat ini Safari Technology Preview dan demo menggunakan nilai masonry sesuai Editor’s Draft, tetapi nama tersebut dapat berubah di masa depan

1 komentar

GN⁺ 2024-04-24

Pendapat di Hacker News

Latar belakangnya adalah para penanggung jawab hubungan developer CSSWG dari vendor browser telah mendiskusikan cara memasukkan layout Masonry secara resmi ke CSS. Diskusi ini sudah berlangsung setidaknya sejak Firefox pertama kali mengusulkannya pada 2020
Kabar kali ini adalah pihak WebKit membawa diskusi ini ke ruang publik dan meminta desainer serta developer untuk bertindak, misalnya “unggah di media sosial, tulis posting blog”
Dari luar ini mungkin tampak seperti prosedur formal, tetapi bisa menjadi preseden penting. Pokok persoalannya adalah apakah semua opsi layout akan diperlakukan sebagai bagian dari CSS Grid, atau apakah setiap kali diperlukan akan terus ditambahkan properti CSS Display baru
Opsi pertama akan membuat spesifikasi CSS Grid yang sudah kompleks menjadi lebih kompleks lagi, sementara opsi kedua bisa membuat spesifikasi CSS membengkak dengan properti dan subproperti baru. Keduanya tidak semudah kelihatannya
- Alasan muncul ketegangan saat menumpangkan Masonry di atas Grid adalah karena keduanya bekerja dengan cara yang pada dasarnya berbeda
  Grid terlebih dahulu menempatkan semua item ke dalam kisi, misalnya menaruhnya seperti col:2,row:3, lalu menentukan ukuran kisi. Masonry idealnya ingin menentukan ukuran track terlebih dahulu, lalu menempatkan item ke track tersebut
  Implementasi awal Firefox dan spesifikasi saat itu pada dasarnya menyatakan bahwa, kecuali baris pertama dan beberapa aturan rumit, item Masonry tidak diperhitungkan dalam kalkulasi ukuran track, sehingga item sangat mudah meluap keluar dari track
  Spesifikasi saat ini mengharuskan semua item dicoba ditempatkan di semua track yang memungkinkan. Dalam kasus terburuk yang juga cukup umum, ini menghasilkan performa kuadratik O(N_tracks * N_items), dan performa kuadratik itu buruk[1]; pada algoritma layout lain pada dasarnya tidak ada hal seperti ini
  Jika ditambah nesting, performanya memburuk secara subeksponensial, dan CPU yang cepat pun tidak membuatnya baik. Bisa saja dikatakan kasus seperti ini tidak umum, tetapi dalam mode layout CSS orang selalu menguji batasnya, jadi secara mendasar harus cepat
  Di Grid, karena item menentukan ukurannya secara berbeda tergantung track tempat ia diletakkan, perlu mencoba menempatkannya di semua posisi yang memungkinkan. Untuk mengurangi masalah seperti ini, Masonry mungkin membutuhkan algoritma lain dalam kalkulasi ukuran track, tetapi posting blog tersebut tidak cukup membahas persoalan ini. Mungkin saja dulu ada versi kalkulasi ukuran Grid tanpa ketergantungan pada posisi item, tetapi kapal itu sudah telanjur berlayar
  [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
- Grid “tanpa baris” cukup cocok dengan spesifikasi CSS Grid saat ini. Alasannya, ia dapat memakai ulang properti definisi kolom yang kuat dan subgrid, dan contoh-contohnya juga menunjukkan dengan meyakinkan betapa ortogonalnya fitur-fitur ini satu sama lain
  Secara umum, cukup memakai grid-row-template: masonry dan sisanya tetap bekerja dengan baik. Ini hal yang bagus, dan menurut saya tidak membuat layout Grid lebih sulit digunakan dibanding sekarang
  Kekurangannya terutama ada pada penulis engine browser. Sebab standar untuk “dukungan penuh CSS Grid” menjadi lebih tinggi. Selain itu, implementasi yang harus mendukung semua fitur Grid dikatakan bisa menghindari jebakan performa yang dapat membuat sebagian layout Grid lebih lambat dibanding ketika spesifikasinya lebih sederhana
  Jika ada mode display terpisah, spesifikasi grid-column harus diulang untuk layout Masonry, dan itu disayangkan
- Ini bukan pertama kalinya hal semacam ini diserahkan ke umpan balik komunitas. Pada nested CSS selector juga dilakukan dengan cara yang sama, dan dari sisi umpan balik hasilnya cukup baik: https://webkit.org/blog/13607/help-choose-from-options-for-c...
- Saat mengeksplorasi titik kompromi, kita bisa jadi memikirkan ulang preferensi awal
  Tidak terkait langsung dengan CSS Masonry, tetapi baru-baru ini saya membuat prototipe iterasi kedua dari sebuah antarmuka yang memiliki ketegangan serupa. Persoalannya adalah apakah perlu menambah tipe yang mirip tetapi berbeda dalam model data, atau menambah nuansa detail di dalam tipe yang sudah ada untuk mendukung penyempurnaan
  Pada awalnya saya sangat memilih yang terakhir, tetapi setelah benar-benar mengeksplorasi opsinya, ternyata jauh lebih sederhana untuk mengonsumsi antarmuka yang “membengkak” dan kemudian menalar kode aplikasi dari hasilnya
  Saya tidak punya posisi kuat soal CSS Masonry, tetapi mungkin ada kejutan serupa antara ketegangan yang secara intuitif dibayangkan orang dan rasa penggunaannya dalam praktik. Khusus untuk CSS, “pembengkakan”, yakni bertambahnya makna per kasus penggunaan, akan sulit dibenarkan, tetapi pengguna juga mungkin cenderung merasa API yang padat seperti Grid lebih sulit
- Bagus bahwa ini dilakukan secara terbuka. Sejak tahun lalu saya terus mendorong semua pihak yang terkait. Pihak Chrome paling tertinggal dan belum punya dukungan. Firefox memiliki dukungan di balik flag
  Sejak tahun lalu saya mengujinya di Firefox dan Safari, dan tidak ada keluhan terhadap implementasinya. Ada juga orang yang menggerutu soal posisi dan nama properti, tetapi kita perlu mengakui bahwa solusi sempurna mungkin tidak ada dan menerapkannya secara pragmatis
  Saya menolak memakai JavaScript untuk implementasi fallback. Karena itu, cara fallback berisi banyak CSS jelek yang tidak bisa mengatur urutan dengan benar, tetapi untuk proyek yang sedang saya kerjakan ini bukan masalah besar. Saat ini kebanyakan orang akan memakai JavaScript sebagai fallback, tetapi jika solusi untuk layout adalah JavaScript, itu berarti kita sudah kalah sejak awal
Demo megamenu <https://webkit.org/demos/grid3/megamenu/> benar-benar tidak saya sukai, dan penggunaan Masonry di sana terlihat sama sekali tidak tepat. Itu mengacaukan arah alur dan sangat melanggar ekspektasi
Urutan baca yang diharapkan: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
Urutan yang diberikan demo sebenarnya: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... Ini memengaruhi urutan baca yang benar dan indeks tab. Pengguna visual pada dasarnya hampir selalu akan membaca dalam urutan yang “salah”
Pada akhirnya ini menunjukkan bahwa strukturnya tidak ada, hanya sekantong tautan yang tidak terstruktur. Padahal kalau diikuti sesuai urutan nomor, tampaknya ada urutan yang cukup logis, tetapi semuanya hancur total karena dijadikan Masonry secara tidak tepat
Di tangkapan layar, “tampilkan nomor item” diaktifkan. Biasanya tampil seperti kolom biasa tanpa latar belakang
Implementasinya seharusnya menggunakan kolom, tetapi menambahkan break-inside: avoid pada setiap bagian. Demo ini melewatkan hal itu
Demo koran juga sedikit mencurigakan karena alasan serupa, tetapi masalahnya jauh lebih kecil
Untuk blok yang lebih independen seperti media semacam gambar, yang urutan bacanya tidak begitu melekat, layout Masonry lebih cocok. Meski begitu masih ada bagian yang agak ambigu di sekitar indeks tab, tetapi setidaknya tidak lagi jelas-jelas salah
- Jika maksudnya pohon aksesibilitas dan urutan tab melewati urutan konten sebenarnya lalu menelusuri kolom satu per satu, saya menganggap itu bug
  Dalam layout Masonry, ekspektasi pengguna visual adalah alurnya mengikuti baris visual, bukan ada kesinambungan antar-kolom. Urutan yang diajukan sebagai “di luar dugaan” juga mengikuti itu
  Masalahnya tampak pada urutan tab yang mengabaikan urutan konten asli dan mencoba meniru tampilan visual, dan hampir pasti itu adalah sisa dari cara implementasi saat ini
- Jika hanya melihat pengguna visual, urutan saat ini tampak masuk akal. Cara yang Anda usulkan mengharuskan orang sering menggulir naik-turun untuk melihat item secara berurutan, dan jika item ditambahkan lagi, bisa terjadi pergeseran layout besar
- Kalau hanya ingin efek Masonry, bukankah cukup memakai layout multi-kolom CSS yang sudah didukung luas?
- Itu cuma demo acak, dan sepertinya tidak terlalu terkait dengan konsep mengumpulkan umpan balik itu sendiri
Hal bagus dari fitur ini adalah saat demo dilihat di browser yang belum mendukungnya, yaitu semua browser stabil saat ini tanpa mengaktifkan flag khusus, karena dibuat langsung di atas layout Grid, tampilannya menjadi format baris tetap yang cukup masuk akal: https://webkit.org/demos/grid3/
Dalam setiap kasus, layout Masonry yang benar tentu akan jauh lebih enak dilihat, tetapi tanpa itu pun masih cukup bisa dipakai. Jika tidak suka, bisa melakukan deteksi fitur dan menyediakan tampilan fallback yang lebih baik
Saya sangat menyukai tampilan dan nuansa umum layout Masonry/waterfall. Mungkin karena saya tumbuh dengan membaca koran kertas dan masih membacanya, layout berbasis kolom terasa seperti cara yang intuitif untuk membagi halaman
Namun saya berharap ada alternatif untuk perataan Masonry default. Sejauh yang saya tahu, aturan dasarnya kira-kira “letakkan item berikutnya di kolom tempat ia bisa masuk paling atas”, dan akibatnya mulai dari baris kedua urutan kiri-kanan menjadi sangat tercampur
Cara yang saya bayangkan lebih baik adalah layout yang lebih mempertahankan alur baca kiri→kanan, atau jika arah yang disukai kanan→kiri, maka arah baca itu. Misalnya, “letakkan item berikutnya di kolom sebelah kanan item sebelumnya; jika sudah paling kanan, letakkan di paling kiri; dan jika dasar baru tidak turun terlalu jauh melewati batas bawah kolom kiri, boleh letakkan item kedua di kolom yang sama”
Ini lebih fleksibel daripada kiri→kanan yang ketat sehingga perataannya juga tidak terlalu rusak, sambil tetap mempertahankan sebagian makna arah baca kiri→kanan
Masonry memang tidak bisa mengakomodasi semua formula yang mungkin disukai, tetapi untuk konten yang urutannya sedikit saja penting—mungkin bukan Pinterest, tetapi kasus seperti jurnal—menurut saya cara seperti ini lebih masuk akal sebagai default daripada aturan Masonry klasik
- Saya hanya akan memakai layout Masonry untuk sesuatu yang sejak awal tidak punya urutan yang jelas. Sepertinya saya tidak akan memakainya untuk gambar yang diurutkan secara kronologis
- Masalahnya adalah perataan kiri→kanan itu sendiri. Dalam layout ini, saya rasa hampir tidak ada cara untuk meratakannya kiri→kanan tanpa melompat-lompat ke sana kemari
  Untuk layout bergaya majalah, bukankah biasanya dibaca dari atas→bawah per kolom dulu, lalu kiri→kanan? Di CSS ini sudah bisa dilakukan dengan columns atau Flexbox arah vertikal
  Masalah lain dari layout Masonry ini adalah bagian bawahnya bergerigi. Kalau di majalah, kemungkinan akan dibuat rata, dan ini juga bisa dilakukan dengan kolom atau Flexbox
  Di web tampaknya ada asumsi tersembunyi bahwa kontennya bergulir tanpa akhir, sehingga bentuk bagian bawah halaman dianggap tidak penting. Kalau begitu, itu bukan asumsi yang pantas didorong
- Bagaimana kalau seperti ini:
  { /* Saat pembaruan, pindahkan elemen ke kiri atau kanan maksimal 2 kolom */ grid-template-max-horizontal-shift: 2 col; }
Andaikan kita bisa membuat sistem yang tidak kompatibel ke belakang untuk menggantikan CSS, apa yang sebaiknya dilakukan?
Apakah ada buku atau makalah tentang cara membuat sistem tata letak yang konsisten?
Bagaimana dengan alternatif seperti Qt, Tk, SwiftUI? Saya belum pernah memakai apa pun selain CSS. Kalau ada sistem yang benar-benar banyak diimplementasikan dan lebih baik, apa yang membuatnya lebih baik?
Saya menginginkan sistem yang memberi antarmuka lebih baik bagi developer, tetapi tidak tahu harus bagaimana. Jika bisa mulai dari nol, apa prinsip desainnya?
- Saya tidak secara khusus anti-CSS, tetapi mungkin tertarik pada konsep seperti grup ukuran, siklus permintaan-alokasi ukuran yang dapat diprediksi, lebar berdasarkan tinggi, serta tata letak berbasis constraint dan alignment. Selain itu, secara umum perlu merapikan kekacauan konsep-konsep yang saling terjerat secara tidak ortogonal di CSS
  Properti harus lebih eksplisit dan terpisah. Hilangkan omong kosong seperti margin negatif, dan semua jarak harus dibuat bertingkat. Misalnya seperti padding = max(el.paddings[])
  Boundary box harus dibuat eksplisit, dan border harus dijadikan elemen yang benar. Box model itu sendiri bukan hal buruk; implementasi CSS-lah yang mengerikannya. Ia penuh mantra rapuh dan batasan absurd yang 99% akan rusak setiap kali disentuh, dan batasan-batasan itu melahirkan lebih banyak masalah dan “solusi”
- Tata letak berbasis constraint yang memakai algoritma Cassowary sempat terlihat seperti alternatif populer: https://github.com/slightlyoff/cassowary.js/?tab=readme-ov-f...
  Pendekatan ini dirancang untuk menyelesaikan perubahan ukuran dan bentuk layar. Apple sudah beralih ke SwiftUI dan mungkin telah meninggalkan pendekatan ini
- Akan sangat menarik kalau ada tulisan yang membandingkan berbagai sistem styling/tata letak. Namun tampaknya tidak banyak orang yang punya pengalaman dengan banyak bahasa styling, jadi tidak banyak pula yang bisa menulisnya
  Flutter dan XAML juga sepertinya layak ditinjau
- Hal yang perlu diperhatikan saat memilih preseden untuk dijadikan referensi adalah bahwa CSS menetapkan standar yang cukup tinggi untuk kontrol deklaratif. Saya tidak bisa menjelaskan secara rinci hal-hal yang disebutkan, tetapi preseden yang lebih sebanding mungkin bisa ditemukan pada kasus penggunaan di bidang percetakan
- Untuk buku klasik tentang topik ini, sepertinya ada "Rastersysteme für die visuelle Gestaltung - Grid systems in Graphic Design". Saya belum membacanya
Saya unggah ulang sebagai komentar tingkat atas agar lebih terlihat
Saya punya situs web fotografi, dan tidak menggunakan JavaScript untuk tata letaknya. Saat membuatnya, saya meninjau library JavaScript Masonry, tetapi hasilnya tidak memuaskan
Tata letak Masonry yang benar-benar mengisi semua ruang yang tersedia pada praktiknya akan memotong sebagian gambar. Jika ingin mempertahankan rasio aspek tanpa memotong, harus menyisakan ruang kosong di sekitar foto. Satu-satunya cara untuk tidak melakukan itu adalah infinite scroll, dan mungkin itulah yang diinginkan mesin adiktif korporat, tetapi bukan itu yang saya inginkan di situs web saya
Saya membuatnya seperti ini:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
Untuk mendapatkan hasil ini saya memakai display:inline-block, pada dasarnya memperlakukan foto seperti teks yang harus di-reflow ke baris baru. Saya sangat puas dengan hasilnya dan lebih menyukainya daripada cara kerja library Masonry
- Tata letak ini kemungkinan bisa diimplementasikan hanya dengan beberapa baris CSS menggunakan Flexbox arah baris yang wrap dan diratakan ke tengah. Itu juga cara yang lebih standar
- Saya tidak memakai JavaScript untuk tata letak Masonry. Saya menyediakan tampilan fallback dengan solusi CSS yang didukung pada solusi CSS Masonry saat ini
  Masalahnya adalah urutan. Jika urutan tidak penting, solusi CSS-only yang ada sekarang juga bekerja dengan baik. Namun seingat saya, bagian bawah kolom bisa menyisakan bentuk yang aneh
- Tata letak seperti ini memang tujuan desain Flexbox, jadi itu juga bisa menjadi pilihan di sini
Terkait hal ini, saya membuat demo interaktif yang membahas prinsip Grid:
https://cssprinciples.com/3/grid/
Ada float lama, dan sekarang juga ada layout Flexbox serta Grid modern; jadi saya bertanya-tanya apakah memang tepat untuk terus menambahkan opsi “layout” ke CSS.
Jika masih ada kasus yang belum tercakup, mungkin solusi yang lebih baik adalah memiliki satu sistem berbasis constraint terakhir yang mencakup semua kasus layout, meski menjadi lebih kompleks. Dengan begitu, framework CSS dan pustaka utilitas bisa membangun Masonry Grid generasi berikutnya dan sebagainya di atasnya
- Saya skeptis apakah sistem constraint benar-benar akan dipertimbangkan. Selama ini CSS sangat menargetkan prediktabilitas biaya layout.
  Meski begitu, proposal layout Houdini adalah yang paling mendekati gagasan ini. Caranya adalah menyerahkan layout ke konteks JavaScript yang terisolasi: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
  Namun sejujurnya, Flexbox dan Grid, serta hal-hal seperti containment, sudah menyelesaikan banyak masalah, sehingga kebutuhan perbaikannya jauh berkurang dibanding era sebelum Flexbox
- Inti dari gerakan ini adalah berhenti memakai hack float lama atau hack CSS Grid/Flexbox yang sebentar lagi juga akan usang. Layout Masonry di Firefox sebenarnya menambahkan satu properti baru yang melipat baris Grid, jadi pada dasarnya diimplementasikan dengan cara yang mencakup semua kasus layout
- Ini adalah Grid level 3. Bisa dilakukan seperti ini:
  display: grid;
  grid-template-rows: masonry;
  Namun terbatas pada WebKit. Saya sempat mengimplementasikannya pada mode galeri feed berita pribadi, tetapi sudah membuangnya pada Oktober 2023
- JavaScript adalah sistem layout final. Tidak ada bahasa deklaratif yang bisa menangani semua use case. Untungnya, sejak Grid hadir, kebutuhan bergantung pada JavaScript menjadi jarang.
  Sistem berbasis constraint tampaknya akan berada di posisi canggung di antara Grid dan JavaScript, jadi saya tidak yakin akan banyak membantu
- Jika ada kebutuhan yang tidak didukung langsung oleh layout CSS, Anda selalu bisa membuat layout dengan JavaScript
Saya sudah memakai ini. Di Firefox saya mengaktifkannya lewat opsi dan menggunakannya untuk bookmark. Di mobile tidak jadi masalah karena semuanya hanya ditumpuk dari atas ke bawah. Di mobile tidak ada about:config
Gambar terakhir adalah keadaan saat dimatikan
https://imgur.com/a/o7OyZEW
- Sejauh yang saya pahami, aturan layout Masonry mengisi ruang kosong tertinggi terlebih dahulu per baris, sehingga menghasilkan perataan yang tidak beraturan. Namun secara visual terlihat seperti tersusun dalam kolom.
  Jadi jika ukuran jendela diubah, urutan bookmark akan berubah
- Coba gunakan Firefox Beta di mobile :)
Lebih banyak latar belakang dan argumen dari sisi sebaliknya—yakni pembahasan bahwa display: masonry lebih baik daripada display:grid + grid-template-rows: masonry—bisa dibaca lebih detail di sini: https://github.com/w3c/csswg-drafts/issues/9041

Permintaan Masukan WebKit untuk Standardisasi Layout ‘Masonry’ CSS Grid Level 3

Posisi CSS Grid Level 3 Saat Ini

Mengapa Layout Masonry Dibutuhkan

Riwayat Usulan dan Perdebatan Standardisasi

Cara Pakai Dasar: Grid yang Mematikan Baris dan Hanya Memakai Kolom

Alasan Mempertahankan Kemampuan Grid dalam Mendefinisikan Kolom

Spanning, View Transitions, dan Columnar Grid

Perbedaan Modular Grid dan Columnar Grid

Menggabungkan Subgrid dan Penempatan Eksplisit

Isu dengan display: masonry

Bagaimana Melihat “Grid”

Masukan yang Diminta dari Developer dan Desainer

Diskusi Nama: masonry, waterfall, off

Bacaan terkait

1 komentar

Pendapat di Hacker News

Isu dengan `display: masonry`

Diskusi Nama: `masonry`, `waterfall`, `off`