CSS Grid Level 3 ‘Masonry’ düzeninin standartlaştırılması için WebKit’ten geri bildirim çağrısı

(webkit.org)

2 puan yazan GN⁺ 2024-04-24 | 1 yorum | WhatsApp'ta paylaş

WebKit, CSS’te uzun süredir zorlayıcı olan masonry/waterfall düzeninin CSS Grid Level 3 kapsamında standartlaştırılması sürecinde tasarımcılardan ve geliştiricilerden geri bildirim istiyor
Önerilen model, display: grid üzerinde grid-template-rows: masonry ile satır oluşturmayı kapatıp içeriği tuğla gibi boş alanlara doldurma yaklaşımına dayanıyor
Apple, bu özelliğin Grid içinde olması gerektiğini; böylece fr, minmax(), max-content, spanning, açık yerleştirme, subgrid gibi mevcut Grid yetenekleriyle birleşebileceğini düşünüyor
Ayrı bir display: masonry yaklaşımı düzen tipini basitçe ayırabilir; ancak tartışmalara göre bunun eşit genişlikte sütunlar odağında sınırlanma olasılığı var ve Grid’in track boyutlandırma yeteneklerini kullanmak zorlaşabilir
Ekim 2024 güncellemesinden sonra CSS Working Group, değişken genişlikli track’lerin, açık yerleştirmenin, spanning’in ve subgrid’in masonry’ye dahil edilmeye değer olduğu ve performanslı şekilde uygulanabileceği sonucuna vardı; ancak söz dizimi tartışmaları sürüyor

CSS Grid Level 3’ün mevcut konumu

Ekim 2024 güncellemesinden sonra CSS Grid Layout Module Level 3 için resmi W3C Working Draft oluşturuldu ve masonry düzeninin davranış biçimi belgelendi
CSS Working Group üyeleri, aşağıdaki özelliklerin masonry düzenine dahil edilmeye değer olduğu ve performanslı biçimde uygulanabileceği sonucuna vardı
- Değişken genişlikli track’ler
- Açık yerleştirme
- Spanning
- subgrid
Ancak söz dizimine dair tartışma hâlâ açık; WebKit bunu ayrı bir yazı olan Help us choose the syntax for Masonry in CSS üzerinden sürdürüyor

Masonry düzeni neden gerekli

CSS Grid Level 1, 2017’de tanıtılarak float tabanlı düzenlerdeki boyutlandırma ve yerleştirme yükünü azalttı; Grid Level 2 ise Subgrid sundu
Ancak CSS Grid çıktıktan sonra bile “masonry düzeni CSS ile nasıl yazılır?” sorusuna 7 yıl boyunca net bir yanıt yoktu
Masonry düzeni, içeriğin tuğla ya da taş duvar gibi birbirine geçerek yerleştiği bir kalıptır; waterfall layout olarak da adlandırılır
Farklı en-boy oranlarına sahip içerikleri yönetebilir; böylece tüm öğeleri aynı dikdörtgene dönüştürmek için kırpma veya küçültme ihtiyacı azalır
İçerik sayfa geneline dağıldığı için kaydırma sırasında okuma sırası doğal biçimde korunur ve alta lazy-load ile içerik eklendiğinde mevcut içeriği oynatmak gerekmez

Önerinin geçmişi ve standartlaştırma tartışması

CSS’te masonry düzeni oluşturma mekanizması ilk olarak Mozilla tarafından Ocak 2020’de CSS Grid genişletmesi olarak önerildi ve Firefox Nightly’de bir bayrağın arkasında deneysel özellik olarak uygulandı
Apple, 2022’de Safari Technology Preview’da CSS Grid Level 3 önerisini uygulamaya başladı; şu anda varsayılan olarak açık
CSS Working Group içinde temel yön konusunda görüş ayrılıkları vardı
- Bazıları masonry’nin CSS Grid’in parçası değil, ayrı bir display tipi olması gerektiğini düşündü
- Bazıları bu düzenin web için gerekli olup olmadığından, ünlü web sitelerinin kullanıp kullanmayacağından emin değildi
WebKit, tarayıcıların bu özelliği yayımlayabilmesi için önce CSS Working Group uzlaşısının gerekli olduğunu düşünüyor

Temel kullanım: satırları kapatıp yalnızca sütunları kullanan Grid

Klasik masonry/waterfall düzeni, main öğesine display: grid uygulayıp sütunları tanımladıktan sonra satır yönüne masonry değeri verilerek yazılır

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)), en az 14rem genişlikte esnek sütunları tekrarlı olarak oluşturur
gap: 1rem, sütunlar ve öğeler arasında 1rem boşluk oluşturur
grid-template-rows: masonry, tarayıcıya satır oluşturma ve içeriği masonry/waterfall kalıbıyla doldur talimatı verir
Bu örnek, medya sorgusu veya container query olmadan dört satır CSS ile farklı ekran boyutlarına uyum sağlayan esnek bir düzen oluşturur
Şu anki masonry değer adının tarayıcılar yayımlanmadan önce değişme olasılığı var

Grid’in sütun tanımlama yeteneklerini koruma nedeni

WebKit, masonry’nin CSS Grid’in parçası olması gerektiğine dayanak göstermek için dört demo hazırladı; bunlar webkit.org/demos/grid3 adresinden doğrudan denenebilir
Demolar, Grid Level 3’ü destekleyen tarayıcılarda görülebilir
- Safari Technology Preview
- Firefox’ta masonry grid layout feature flag açıldığında
CSS Grid, sütun tanımlarken çeşitli seçenekler sunar
- px, em, rem, cqi, lh, ch, ic, cap, vw, svh gibi çeşitli birimlerde sabit boyutlar
- max-content, min-content
- fr birimi
- minmax()
- % boyutları
- auto
Örneğin ilk ve son sütun 14ch sabit genişlikte bırakılıp orta sütunlar en az 28ch olan esnek sütunlar yapılabilir

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

fr birimi ve minmax() birleşimiyle sütunların farklı aşamalarda genişleyip daraldığı iki aşamalı esneklik oluşturulabilir
max-content ve min-content, sütun boyutlarını içerik boyutuna uydurarak içeriği sütuna uydurma yaklaşımından farklı yerleşimleri mümkün kılar
grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr; gibi Fibonacci dizisi kullanılarak farklı genişliklerde sütunlar da oluşturulabilir
Mega menu örneği, grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); kullanarak her sütunun bağlantı metnini satır kırmadan barındırabilecek kadar büyümesini sağlar
WebKit, ayrı display: masonry tartışmasının bugünkü multicolumn layout gibi yalnızca eşit boyutlu sütunlara izin verme yönünde olduğunu düşünüyor

Spanning, View Transitions, columnar grid

CSS Grid, öğelerin birden fazla sütuna yayılmasını sağlayabildiği için masonry yerleşiminde de çeşitli görsel kompozisyonlar mümkün olur
Örnekte her 5. görselin iki sütuna yayılması, diğer görsellerin ise tek sütun kaplaması sağlanabilir
Daha geniş en-boy oranına sahip görsellere wider sınıfı verilerek birden fazla sütun kaplamaları, köşelerin dikdörtgen yapılması veya boşluğun 0’a düşürülmesi gibi varyasyonlar da mümkündür
Photos demosu, View Transitions ile birleşerek kullanıcı bir fotoğrafa tıkladığında veya dokunduğunda fotoğrafın birden fazla sütuna yayılıp büyümesini ve tarayıcının geçişi otomatik olarak canlandırmasını sağlar
- Bu demo Safari Technology Preview 192 veya üzerini gerektirir
WebKit, Grid Level 3’ün özünü “masonry” adlı belirli kalıptan çok satırları kapatma mekanizması olarak görüyor
Bu yöntem yalnızca sütunlardan oluşan bir columnar grid oluşturur; CSS Grid Level 1’in iyi oluşturduğu, satır ve sütunların birlikte hizalandığı modular grid ile karşıtlık gösterir

Modular grid ile columnar grid arasındaki fark

Modular grid, içeriğin hem sütunlara hem satırlara hizalandığı Grid’dir; CSS Grid Level 1 bu tür yerleşim için uygundur
Float tabanlı düzenlerde de float’ın doğru şekilde toparlanması için içerik yüksekliklerinin eşitlenmesi gerektiğinden, web’de modular grid kullanımını teşvik etmiştir
Gerçek web sitelerinde görsellerin en-boy oranını eşitlemek, metin uzunluklarını dengelemek veya CMS politikaları ya da CSS kırpma ve üç noktayla kısaltma yoluyla içeriği aynı kutuya uydurmak sık görülür
Columnar grid, içeriğin istediği boyutu korumasına izin verip düzenin içeriğe göre çalışmasını sağlayabilir
WebKit, en yeni makaleyi dört sütuna yayma, daha yeni bazı makaleleri iki sütuna, eski içerikleri ise tek sütuna yerleştirme örneğiyle metin ağırlıklı içeriğin de daha canlı biçimde düzenlenebileceğini düşünüyor

Subgrid ve açık yerleştirmenin birleşimi

CSS Grid Level 2’deki subgrid, çoğu tarayıcı tarafından destekleniyor
Müze sayfası örneği, resim kartlarının meta verilerini sol hizalı tek bir sütunda listelemek yerine subgrid ile yılı ve katalog numarasını her kartın sağına yerleştiriyor ve diğer kartlardaki aynı verilerle aynı hizaya getiriyor
Masonry CSS Grid Level 3’e girerse mevcut geliştirici araçları da aynen kullanılabilir
- Safari Technology Preview’daki Grid Inspector ile grid-template-rows: masonry denenebilir
Ayrı bir display tipi olursa subgrid’in avantajları elde edilemez
CSS Grid Level 1’in açık yerleştirmesi de birlikte kullanılabilir; örnekte grid-column: -3 / -1 ile başlık son iki sütunda sayfanın sağ üstüne yerleştirilir
WebKit, birkaç satır düzen koduyla Grid Level 1, 2 ve 3 özelliklerini birleştirerek medya sorgusu veya container query olmadan kullanılabilir boyuta göre sütun sayısı değişen düzenler oluşturulabileceğini düşünüyor

`display: masonry` ile ilgili tartışmalı noktalar

WebKit ve Apple, Masonry’yi CSS Grid’i genişleterek yalnızca modular grid değil columnar grid de oluşturulmasını sağlayan bir özellik olarak görüyor
Bu yönde sütun tanımlama, track spanning, açık yerleştirme, subgrid gibi Grid özellikleri birlikte kullanılabilir
Ayrı display tipini tercih edenler, düzen tiplerinin temiz biçimde ayrılabileceğini düşünüyor

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

CSS Working Group ayrı Masonry display type söz dizimini henüz tartışmadı; ancak WebKit, Multicolumn layout’a benzer söz dizimini veya sınırlı Grid benzeri söz dizimini örnek veriyor

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

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

Ayrı düzen tipi, Grid ile Masonry’yi sürekli birlikte çalıştırmak için gereken işlerden kaçınabilir
- Düzen modeli basitleşir
- Tarayıcı uygulaması kolaylaşır
- Performans tuzakları olasılığı azalır
- Grid ve Masonry özellik setleri birbirinden farklılaşabilir
Buna karşılık WebKit, iki Grid düzeni türü bağlı kalırsa CSS Working Group’un gelecekteki özellikleri hem modular grid hem columnar grid için tanımlayacağını düşünüyor
Örneğin CSS Grid Level 4’te grid area ve grid line stillendirme, track arka plan renkleri, gap için rule line gibi özellikler eklenirse bunların baştan iki Grid türünde de çalışması daha iyi görülüyor

“Grid”e nasıl bakılmalı

Ayrı display: masonry yaklaşımını destekleyenler, CSS Grid’in özünde iki boyutlu hizalama olduğunu ve masonry’nin yalnızca tek yönde hizalandığı için Grid olmadığını düşünebiliyor
WebKit, grafik tasarım tarihinde grid’in metin, görsel ve içeriği düzenli kalıplarla hizalayarak okunabilirliği ve kullanılabilirliği artıran bir araç olduğunu düşünüyor
1. yüzyıl Avrupa ve Amerikan modernistleri, hem sütun hem satır hizalamasını “proper” graphic design grid olarak vurgulamadan önce de çeşitli grid’ler kullanılıyordu
Mark Boulton, simetrik columnar grid’in resmi ve sıkıcı olduğunu düşünüp web tasarımında asimetrik compound grid kullanımını teşvik etmişti
CSS Grid Level 1, asimetrik grid ve compound grid oluşturmayı kolaylaştırdı; ancak şu anda bu yalnızca söz konusu Grid modular grid olduğunda geçerli
WebKit, modular grid ve columnar grid’in ikisinin de grid olduğunu ve CSS Grid’in de columnar grid oluşturma yeteneğine sahip olması gerektiğini düşünüyor

Geliştiricilerden ve tasarımcılardan istenen geri bildirim

WebKit, geliştiricilerin ve tasarımcıların demoları bizzat oluşturmasını, bloglarda veya sosyal medyada görüş yazmasını ve CSS Working Group issue’larına yorum bırakmasını istiyor
Geri bildirim soruları şunlar
- “masonry”/“waterfall” CSS Grid’in parçası olmalı mı
- subgrid, spanning, açık yerleştirme ve çeşitli track sizing seçeneklerini içeren columnar grid yetenekleri gerekli mi
- Eşit boyutlu sütunlardan oluşan klasik masonry düzeni yeterli mi
- Bu özelliği gerçekten kullanır mısınız, neler oluşturabilirsiniz
- Oluşturduğunuz demo bağlantısı var mı
- Bu modelle yapılamayan bir şey var mı
WebKit ekibi Masonry üzerinde bir buçuk yıldır çalışıyor ve özellik Şubat 2023’te Safari Technology Preview 163 ile varsayılan olarak etkinleştirildi
Özelliği yakında yayımlamak istiyorlar; ancak ad dahil ayrıntıların ve temel soruların önce çözülmesi gerekiyor

Ad tartışması: `masonry`, `waterfall`, `off`

WebKit, masonry’nin yeni değer için en iyi ad olmama ihtimalinin yüksek olduğunu düşünüyor
CSS adları genellikle center, contain, clip, wrap, smooth gibi sonucu doğrudan açıklayan basit kelimelerden oluşur
masonry, arka plan açıklaması gerektiren bir metafor olduğundan İngilizce konuşmayan geliştiriciler için hatırlaması zor olabilir
Bazı bölgelerde bu düzen daha çok waterfall olarak adlandırıldığı için grid-template-rows: waterfall da olası bir aday olabilir
WebKit, bu özelliği Pinterest türü düzenin kendisinden çok “Grid oluştur ama satır oluşturma” mekanizmasına yakın görüyor
grid-template-rows: none; anlam açısından uygun olabilir; ancak none zaten grid-template-* için varsayılan değer olarak “açık satır olmadan yalnızca örtük satırlar ver” anlamına geldiğinden kullanılamaz
Alternatif olarak grid-template-rows: off; öneriliyor

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

CSSWG ad konusunu bu issue’da tartışıyor
Şu anda Safari Technology Preview ve demolarda Editor’s Draft’a uygun olarak masonry değeri kullanılıyor; ancak gelecekte ad değişebilir

1 yorum

GN⁺ 2024-04-24

Hacker News yorumları

Arka plan, tarayıcı üreticilerinin CSSWG geliştirici ilişkileri sorumlularının Masonry düzenini CSS'e resmen dahil etmenin yolunu tartışıyor olması. Bu tartışma en azından Firefox'un ilk önerdiği 2020'den beri sürüyor
Bu haberdeki yenilik, WebKit tarafının bu tartışmayı kamuya açması ve tasarımcılar ile geliştiricilerden “sosyal medyada paylaşın, blog yazısı yazın” gibi eylemler istemesi
Dışarıdan biçimsel bir prosedür gibi görünebilir ama önemli bir emsal olabilir. Temel tartışma noktası, tüm düzen seçeneklerinin CSS Grid'in bir parçası olarak mı ele alınacağı, yoksa ihtiyaç oldukça yeni CSS Display özellikleri eklemeye devam mı edileceği
İlki zaten karmaşık olan CSS Grid spesifikasyonunu daha da karmaşıklaştırır; ikincisi ise CSS spesifikasyonunu yeni özellikler ve alt özelliklerle şişirebilir. Hangisi olursa olsun, göründüğü kadar kolay değil
- Masonry'yi Grid'in üzerine bindirmede gerilim yaşanmasının nedeni, ikisinin temelde farklı çalışması
  Grid önce tüm öğeleri ızgaraya yerleştirir; örneğin col:2,row:3 gibi konumlandırdıktan sonra ızgara boyutunu belirler. Masonry ise ideal olarak önce iz boyutlarını belirleyip sonra öğeleri bu izlere yerleştirmek ister
  Firefox'un ilk uygulaması ve o zamanki spesifikasyon, temel olarak ilk satır ve bazı karmaşık kurallar dışında Masonry öğelerinin iz boyutu hesaplamasında dikkate alınmadığını söylüyordu; bu yüzden öğelerin izlerin dışına taşmasına yol açmak çok kolaydı
  Mevcut spesifikasyon, tüm öğelerin mümkün olan tüm izlere yerleştirilip denenmesini gerektiriyor. En kötü ve oldukça yaygın durumda O(N_tracks * N_items) düzeyinde ikinci dereceden performans ortaya çıkıyor; ikinci dereceden performans kötüdür[1] ve diğer düzen algoritmalarında fiilen böyle bir şey yoktur
  İç içe geçme de eklenince performans yarı üstel biçimde kötüleşir; CPU hızlı olsa bile bu iyi değildir. Bu tür durumların yaygın olmadığı söylenebilir ama CSS düzen modlarında insanlar her zaman sınırları zorladığından, varsayılan olarak hızlı olması gerekir
  Grid'de bir öğe hangi ize yerleştirildiğine bağlı olarak kendi boyutunu farklı belirlediği için, mümkün olan tüm konumlarda denenmesi gerekir. Masonry'nin bu sorunu hafifletmek için iz boyutu hesaplamasında farklı bir algoritmaya ihtiyaç duyması gerekebilir; blog yazısı bu meseleyi yeterince ele almıyor. Grid boyut hesaplamasının öğe konumu bağımlılığı olmayan bir sürümü olabilirdi ama o gemi artık kalktı
  [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
- “Satırsız” Grid, mevcut CSS Grid spesifikasyonuna oldukça iyi uyuyor. Çünkü güçlü sütun tanımlama özellikleri ile alt Grid yeniden kullanılabiliyor ve örnekler de bu özelliklerin birbirinden ne kadar bağımsız olduğunu ikna edici biçimde gösteriyor
  Genel olarak yalnızca grid-row-template: masonry kullanınca geri kalanı olduğu gibi iyi çalışıyor. Bu iyi bir nokta ve Grid düzenini bugünkünden daha zor kullanılır hale getirmediğini düşünüyorum
  Dezavantaj esas olarak tarayıcı motoru yazarları için. Çünkü “CSS Grid'i tam destekleme” çıtası yükseliyor. Ayrıca Grid'in tüm özelliklerini desteklemesi gereken bir uygulamanın, spesifikasyon daha basitken olduğuna kıyasla bazı Grid düzenlerinde yavaşlayabileceği performans tuzaklarından da kaçınabileceği söyleniyor
  Ayrı bir display modu olsaydı, Masonry düzeni için grid-column spesifikasyonunu tekrarlamak gerekirdi; bu da yazık olurdu
- Böyle bir şeyin topluluk geri bildirimine açılması ilk kez olmuyor. İç içe CSS seçicileri sırasında da aynı yöntem izlendi ve geri bildirim açısından oldukça iyi çalıştı: https://webkit.org/blog/13607/help-choose-from-options-for-c...
- Uzlaşma noktalarını keşfederken başlangıçtaki tercihinizi yeniden düşünmek zorunda kalabilirsiniz
  CSS Masonry ile doğrudan ilgili değil ama yakın zamanda benzer bir gerilime sahip bir arayüzün ikinci yinelemesinin prototipini çıkardım. Sorun, veri modelinde benzer ama farklı tipleri çoğaltmak mı, yoksa mevcut tipin içinde daha fazla nüans ekleyerek inceltmeyi desteklemek mi olduğuydu
  Başta ikincisini güçlü biçimde tercih ediyordum ama seçenekleri gerçekten keşfedince, “şişkin” arayüzü tüketmenin ve bunun sonucunda uygulama kodu hakkında akıl yürütmenin çok daha basit olduğu ortaya çıktı
  CSS Masonry konusunda güçlü bir tutumum yok ama insanların sezgisel olarak düşündüğü gerilim ile gerçek kullanım hissi arasında benzer bir sürpriz olabilir. CSS'te özellikle “şişme”, yani kullanım senaryosuna özgü anlamların artması, gerekçelendirmesi zor bir şey olacaktır; ancak kullanıcılar Grid gibi yoğun API'leri daha zor bulma eğiliminde de olabilir
- Bunun bu kadar açık yürütülmesi iyi. Geçen yıldan beri ilgili herkesi sürekli zorluyordum. Chrome tarafı en geride ve hâlâ destek yok. Firefox'ta bayrak arkasında destek var
  Geçen yıldan beri Firefox ve Safari'de test ettim; uygulamadan şikâyetim yok. Özelliğin konumu ve adı hakkında homurdananlar da var ama muhtemelen kusursuz bir çözüm olmadığını kabul edip pratik biçimde uygulamak gerekiyor
  Alternatif uygulamada JavaScript kullanmayı reddediyorum. Bu yüzden yedek yöntem, sıralamayı düzgün tutturamayan çokça çirkin CSS içeriyor ama üzerinde çalıştığım proje için büyük bir sorun değil. Şimdilik çoğu kişi JavaScript ile yedekleyecektir ama düzenin çözümü JavaScript ise zaten oyuna yenik başlıyorsunuz
Mega menü demosu <https://webkit.org/demos/grid3/megamenu/> gerçekten hoşuma gitmiyor; orada Masonry kullanmak tamamen uygunsuz görünüyor. Akış yönünü altüst edip beklentiyi ciddi biçimde bozuyor
Beklenen okuma sırası: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
Gerçek demonun verdiği sıra: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... Doğru okuma sırasını ve tab indeksini etkiliyor. Görsel kullanıcılar fiilen neredeyse her zaman “yanlış” sırada okuyacak
Sonuçta bunun yapısı olmayan, bağlantılarla dolu düzensiz bir torbadan ibaret olduğunu gösteriyor. Ama numara sırasını izleyince oldukça mantıklı bir sıra varmış gibi görünüyor; uygunsuz biçimde Masonry’ye dönüştürüldüğü için tamamen bozulmuş
Ekran görüntüsünde “öğe numaralarını göster” seçeneğini açtım. Normalde arka plansız sıradan sütunlar gibi görünüyor
Uygulama sütunları kullanmalı, fakat her bölüme break-inside: avoid eklemeliydi. Demoda bu atlanmış
Gazete demosu da benzer nedenlerle biraz şüpheli, ama çok daha küçük bir sorun
Görseller gibi daha bağımsız bloklar olan ve okuma sırasının o kadar derine işlemediği medya türlerinde Masonry yerleşimi daha iyi uyuyor. Yine de tab indeksi etrafında biraz muğlaklık var; ama artık açıkça yanlış değil
- Erişilebilirlik ağacı ve tab sırası gerçek içerik sırasını atlayıp sütunları tek tek dolaşıyorsa, bunu hata olarak görürüm
  Masonry yerleşiminde görsel kullanıcının beklentisi, sütunlar arasında süreklilik olması değil, görsel satırları takip etmesidir. “Beklenmedik” diye sunulan sıra da bunu izliyor
  Sorun, tab sırasının özgün içerik sırasını yok sayıp görsel olanı taklit etmeye çalışmasında gibi görünüyor; bu da neredeyse kesinlikle mevcut uygulama biçiminden kalma bir izdir
- Yalnızca görsel kullanıcılar açısından bakınca mevcut sıra makul görünüyor. Önerdiğin yöntem, öğeleri sırayla görmek için sık sık yukarı aşağı kaydırmayı gerektirir ve daha fazla öğe eklenirse büyük yerleşim kaymaları oluşabilir
- Masonry etkisi isteniyorsa, yaygın desteklenen CSS çok sütunlu yerleşim kullanılsa olmaz mı?
- Bu sadece rastgele bir demo; geri bildirim toplama fikrinin kendisiyle pek ilgisi yok gibi görünüyor
Bu özelliğin iyi yanı şu: Desteklemeyen tarayıcılarda, yani özel bayrak açılmamış mevcut tüm kararlı tarayıcılarda demoya baksanız bile, Grid yerleşiminin üzerine doğrudan kurulduğu için oldukça makul bir sabit satır biçiminde gösteriliyor: https://webkit.org/demos/grid3/
Her durumda düzgün bir Masonry yerleşimi olsaydı çok daha güzel görünürdü, ama olmasa da yeterince kullanılabilir. Hoşunuza gitmezse özellik algılama yapıp daha iyi bir yedek görünüm de sunabilirsiniz
Masonry/şelale tipi yerleşimin genel görünümünü ve hissini gerçekten seviyorum. Basılı gazete okuyarak büyüdüğüm ve hâlâ okuduğum için olsa gerek, sütun tabanlı yerleşim sayfayı bölmenin sezgisel bir yolu gibi geliyor
Ancak varsayılan Masonry hizalamasına bir alternatif olmasını isterdim. Bildiğim kadarıyla temel kural “sonraki öğeyi en yukarıya sığabileceği sütuna yerleştir” şeklinde; bu yüzden ikinci satırdan itibaren soldan sağa sıra ciddi biçimde karışıyor
Hayal ettiğim daha iyi yöntem, soldan sağa ya da tercih edilen yön sağdan sola ise o okuma akışını daha fazla koruyan bir yerleşim. Örneğin “sonraki öğeyi önceki öğenin sağındaki sütuna koy; zaten en sağdaysa en sola koy; yeni alt kenar sol sütunun alt sınırından çok aşağı inmiyorsa aynı sütuna ikinci bir öğe koyabilirsin” gibi bir yöntem
Katı soldan sağa düzenden daha esnek olduğu için hizalamayı da daha az bozar ve soldan sağa okuma yönünün anlamını bir ölçüde koruyabilir
Masonry’de tercih edilebilecek tüm formülleri kapsamak mümkün olmayabilir; ama sıranın az da olsa önemli olduğu içeriklerde, Pinterest olmasa bile dergi gibi örneklerde, bunun klasik Masonry kuralından daha makul bir varsayılan olduğunu düşünüyorum
- Başta net bir sırası olmayan şeyler için ancak Masonry yerleşimi kullanırdım. Kronolojik sıralı görsellerde kullanmazdım gibi geliyor
- Sorun soldan sağa hizalamanın kendisi. Bu yerleşimde oradan oraya atlamadan soldan sağa hizalamanın neredeyse bir yolu olmadığını düşünüyorum
  Dergi tarzı bir yerleşimde önce sütunu yukarıdan aşağı, sonra soldan sağa okumaz mıyız? CSS’te bu zaten columns veya dikey yönlü Flexbox ile mümkün
  Bu Masonry yerleşiminin bir başka sorunu da alt tarafının girintili çıkıntılı olması. Bir dergide muhtemelen eşitlenirdi; bu da sütunlar veya Flexbox ile yapılabilir
  Web’de sonsuz kaydırılan içerik gibi gizli bir varsayım var; bu yüzden sayfanın alt tarafının görünümü önemli değilmiş gibi görülüyor. Öyleyse bu, mutlaka teşvik edilecek bir varsayım değil
- Şöyle olsa nasıl olur:
  { /* Güncelleme sırasında öğeleri sola veya sağa en fazla 2 sütun taşı */ grid-template-max-horizontal-shift: 2 col; }
CSS'nin yerini alacak geriye dönük uyumlu olmayan bir sistem yapabileceğimizi varsayarsak, nasıl yapmalıydık?
Tutarlı bir layout sistemi oluşturmanın yolları üzerine kitaplar ya da makaleler var mı?
Qt, Tk, SwiftUI gibi alternatifler nasıl? CSS dışında hiç kullanmadım. Gerçekten yaygın biçimde uygulanmış sistemler arasında daha iyisi varsa, onu daha iyi yapan şey ne?
Geliştiriciye daha iyi bir arayüz sunan bir sistem istiyorum ama nasıl yapılacağını bilmiyorum. Sıfırdan başlayabilseydik tasarım ilkeleri ne olmalıydı?
- Özellikle CSS karşıtı değilim ama boyut grupları, öngörülebilir boyut isteği-tahsis döngüsü, yüksekliğe bağlı genişlik, kısıt ve hizalama tabanlı layout gibi kavramlar ilgi çekici olabilir. Ayrıca CSS'te ortogonal olmayan biçimde birbirine dolanmış kavramların karmaşasını genel olarak toparlamak gerekiyor
  Özellikler daha açık ve ayrık olmalı. Negatif margin gibi saçmalıklar kaldırılmalı; tüm mesafeler çok aşamalı hale getirilmeli. Örneğin padding = max(el.paddings[]) gibi
  Sınır kutusu açıkça oluşturulmalı, border'lar da düzgün öğeler haline getirilmeli. Box model'in kendisi kötü değil; CSS onun uygulamasını berbat yapmış. Dokunduğunuzda %99 kırılan kırılgan büyüler ve tuhaf sınırlamalarla dolu; bu sınırlamalar da daha fazla sorun ve “çözüm” doğuruyor
- Cassowary algoritmasını kullanan kısıt tabanlı layout bir süre popüler bir alternatif gibi görünmüştü: https://github.com/slightlyoff/cassowary.js/?tab=readme-ov-f...
  Ekran boyutu ve biçimindeki değişimleri çözmek için tasarlanmış bir yaklaşım. Apple SwiftUI'ye geçti ve bu yaklaşımdan uzaklaşmış olabilir
- Çeşitli styling/layout sistemlerini karşılaştıran bir yazı gerçekten ilginç olurdu. Ancak birden fazla styling dili deneyimi olan çok kişi olmadığı için böyle bir yazıyı yazabilecek kişi sayısı da muhtemelen azdır
  Flutter ve XAML de incelenmeye değer görünüyor
- Referans alınacak önceki örnekleri seçerken dikkat edilmesi gereken nokta, CSS'in deklaratif kontrol çıtasını oldukça yükseğe koyması. Bahsedilenleri ayrıntılı anlatamam ama daha karşılaştırılabilir önceki örnekler muhtemelen baskı tarafındaki kullanım senaryolarında bulunabilir
- Bu konunun klasik kitabı olarak "Rastersysteme für die visuelle Gestaltung - Grid systems in Graphic Design" var gibi. Okumadım
Daha iyi görünmesi için üst düzey yorum olarak tekrar gönderiyorum
Bir fotoğraf web sitem var ve layout için JavaScript kullanmıyor. Yaparken JavaScript Masonry kütüphanelerini değerlendirdim ama sonuç tatmin edici değildi
Gerçekte kullanılabilir tüm alanı dolduran düzgün bir Masonry layout, bazı görüntüleri kırpar. Kırpmadan en-boy oranını korumak istiyorsanız fotoğrafların etrafında boşluk bırakmanız gerekir. Bunu yapmamanın tek yolu sonsuz kaydırmadır; kurumsal bağımlılık makinelerinin istediği bu olabilir ama kendi web sitemde istediğim şey bu değil
Şöyle yaptım:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
Bu sonucu elde etmek için display:inline-block kullandım; fotoğrafları yeni satıra reflow edilmesi gereken metin gibi ele almış oldum. Sonuçtan çok memnunum ve Masonry kütüphanelerinin yaptığı yönteme tercih ediyorum
- Bu layout muhtemelen satır sonuna geçen ve ortalanan satır yönlü Flexbox ile birkaç satır CSS'le uygulanabilirdi. Bu aynı zamanda daha standart bir yöntem olurdu
- Masonry layout için JavaScript kullanmıyorum. Mevcut Masonry CSS çözümünde, desteklenen bir CSS çözümünü fallback olarak koyuyorum
  Sorun sıra. Sıra önemli değilse mevcut yalnızca CSS kullanan çözüm de iyi çalışıyor. Yalnız hatırladığım kadarıyla sütunların altında tuhaf bir şekil kalabiliyor
- Bu tür layout'lar Flexbox'ın tasarlanma amaçlarından biri olduğu için burada da bir seçenek olabilir
Bununla bağlantılı olarak Grid ilkelerini ele alan etkileşimli bir demo hazırladım:
https://cssprinciples.com/3/grid/
Eski float var, modern Flexbox ve Grid düzenleri de var; CSS’e sürekli “layout” seçeneği eklemeye devam etmek doğru mu, merak ediyorum.
Hâlâ kapsanmayan durumlar varsa, karmaşıklaşsa bile tüm layout senaryolarını kapsayan son bir kısıt tabanlı sistem bulundurmak daha iyi bir çözüm olabilir. Böylece CSS framework’leri ve utility kütüphaneleri bunun üzerinde yeni nesil Masonry Grid vb. oluşturabilir.
- Bir kısıt sisteminin gerçekten değerlendirileceği konusunda şüpheliyim. CSS şimdiye kadar layout maliyetinin öngörülebilirliğini güçlü biçimde hedefledi.
  Yine de Houdini layout önerisi bu fikre en yakın olanı. Layout’u yalıtılmış bir JavaScript bağlamına devretme yaklaşımı: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
  Ama açıkçası Flexbox ve Grid, ayrıca containment gibi şeyler zaten birçok sorunu çözdüğü için Flexbox öncesi döneme kıyasla iyileştirme talebi çok daha azaldı.
- Bu hareketin özü, eski float hack’lerini ya da yakında eskiyecek CSS Grid/Flexbox hack’lerini kullanmayı bırakmak. Firefox’un Masonry layout’u gerçekten Grid satırlarını katlayan yeni bir özellik ekleme yöntemiyle çalışıyor; yani fiilen tüm layout senaryolarını kapsayacak şekilde uygulanmış durumda.
- Bu Grid Level 3. Şöyle yapılabiliyor:
  display: grid;
  grid-template-rows: masonry;
  Ancak WebKit ile sınırlı. Kişisel haber akışımın galeri modunda uygulamıştım, ama daha Ekim 2023’te kaldırdım.
- JavaScript nihai layout sistemidir. Hiçbir bildirime dayalı dil tüm kullanım senaryolarını karşılayamaz. Neyse ki Grid çıktıktan sonra JavaScript’e bağımlı kalmak nadiren gerekiyor.
  Kısıt tabanlı sistem Grid ile JavaScript arasında bir yerde garip biçimde konumlanacak gibi; bu yüzden ne kadar yardımcı olur emin değilim.
- CSS layout’unun doğrudan desteklemediği bir gereksinim varsa her zaman JavaScript ile layout oluşturabilirsiniz.
Bunu zaten kullanıyorum. Firefox’ta seçeneklerden açıp yer imlerinde kullanıyorum. Mobilde zaten sadece alt alta yığıldığı için sorun olmuyor. Mobilde about:config yok.
Son görsel kapalı hâli.
https://imgur.com/a/o7OyZEW
- Benim anladığım kadarıyla Masonry layout kuralları en üstteki boş yeri önce satır bazında doldurduğu için düzensiz hizalanma oluşuyor. Ama görsel olarak sütunlara hizalanmış gibi görünüyor.
  Bu yüzden pencere boyutunu değiştirirseniz yer imi sırası değişecektir.
- Mobilde Firefox Beta’yı deneyin :)
Daha fazla arka plan ve karşı taraftaki argüman, yani display:grid + grid-template-rows: masonry yerine display: masonry’nin daha iyi olduğu tartışması burada ayrıntılı olarak görülebilir: https://github.com/w3c/csswg-drafts/issues/9041

CSS Grid Level 3 ‘Masonry’ düzeninin standartlaştırılması için WebKit’ten geri bildirim çağrısı

CSS Grid Level 3’ün mevcut konumu

Masonry düzeni neden gerekli

Önerinin geçmişi ve standartlaştırma tartışması

Temel kullanım: satırları kapatıp yalnızca sütunları kullanan Grid

Grid’in sütun tanımlama yeteneklerini koruma nedeni

Spanning, View Transitions, columnar grid

Modular grid ile columnar grid arasındaki fark

Subgrid ve açık yerleştirmenin birleşimi

display: masonry ile ilgili tartışmalı noktalar

“Grid”e nasıl bakılmalı

Geliştiricilerden ve tasarımcılardan istenen geri bildirim

Ad tartışması: masonry, waterfall, off

İlgili okumalar

1 yorum

Hacker News yorumları

`display: masonry` ile ilgili tartışmalı noktalar

Ad tartışması: `masonry`, `waterfall`, `off`