CSS Duvar Örgüsü ve CSS Izgarası

 Saf CSS'de masonry düzenleri oluşturma yaklaşımı, bu "kutsal kase" özlemlerinden biridir. Aslında, masonry ve klasik "Kutsal Kase" düzenini web tasarımının aynı genel dönemine koyma eğilimindeyim. Elbette, farklı türde düzenlerdir, ancak CSS Grid'i aldığımızda Kutsal Kase bitmiş bir işti .

Bu, CSS 3 döneminden kalan ve yerleşik bir çözümü olmayan son ayakta kalan düzen olarak duvarcılığı bırakıyor. Duvarcılığın artık moda olmadığını iddia edebilirim , ancak mevcut alana göre değişen boyutlardaki öğeleri sütunlara yerleştirmek için açıkça kullanım örnekleri var. Ve duvarcılık hala çok yaygın.

Steam resmi bir çözüme yöneliyor. Hatta bunun için bir CSSWG taslak şartnamemiz bile var . Ancak taslağın her şeyi nasıl parçalara ayırdığına dikkat edin.

Grid-entegre sözdizimi? Grid-bağımsız sözdizimi? Gittik ve CSS'yi çoğalttık!

Bu notlar grubunun bağlamı budur. Yazma sırasında CSS duvarcılığı için iki rakip teklif var ve birini veya diğerini savunan birçok görüş ortalıkta dolaşıyor. Benim bu konuda kişisel düşüncelerim var ama bu önemli değil. Ne olursa olsun fikir birliğine varmaktan mutluluk duyarım. Her iki teklifin de avantajları var ve potansiyel zorlukları var — bu, neye öncelik verdiğinizle ilgili bir konu, ki bu durumda, mevcut CSS düzen özelliklerini ve yepyeni bir yaklaşımın ergonomisini kullanma arasında bir seçim olduğuna inanıyorum.

Ama gelin, daha net bir resim elde etmek için halihazırda devam eden tartışmalardan bazı notlara göz atalım!

Duvar örgüsü düzeni nedir?

Bunu taş veya tuğladan bir duvar örmek gibi düşünün.

Tuğlaların ve taşların boyutları önemli değildir — sütun (veya daha az yaygın olarak bir sıra) şeylerin boyutlandırılmasının patronudur. En yakın sütuna mümkün olduğunca çok taş veya tuğla koyun ve sonra bunlar sütunun genişliğine uyum sağlar. Ya da daha özlü bir şekilde, aralarında eşit olmayan boşluklar olmayacak şekilde eşit olmayan büyüklükteki öğeleri bir sütuna yerleştiriyoruz.

Örnekler lütfen?

İşte CodePen'de en çok görülen örnek, Dave DeSandro'nun Masonry.js aracını kullanarak yaptığı çalışma :

Bu örneği kullanıyorum çünkü doğru hatırlıyorsam, Masonry.js 2010'da falan masonry trendini körükleyen şeydi. Dave bunu Beyoncé'nin web sitesinde uyguladı ve bu da masonry'ye kesinlikle oldukça görünür bir profil kazandırdı. Bazen masonry'nin "Pinterest tarzı" düzen olarak adlandırıldığını duyabilirsiniz çünkü, eh, bu sitenin imza tasarımıdır — hatta belki de markasıdır — ilk günden beri.

İşte Jhey'in flexbox kullanarak hazırladığı sahte bir örnek:

Chris ayrıca 2019'da bizi ideal koşullar altında bir yere götüren bir sürü başka geçici çözüm de buldu . Ancak bunların hiçbiri standartlaştırılmış yaklaşımlara veya özelliklere dayanmıyor. Yani, sütunlar ve flexbox belirtilmiş ancak masonry düşünülerek tasarlanmamıştı. Ancak masonry'nin uzun süredir kullanıldığı göz önüne alındığında, CSS belirtimlerinde kesinlikle bir yer hak ediyor.

İki rekabet eden teklif var

Bu tam olarak yeni bir haber değil. Aslında, 2020'ye baktığımızda bunun daha erken esintilerini görebiliyoruz. Rachel Andrew , Smashing Magazine makalesinde duvarcılığın ızgaranın bir alt özelliği haline getirilmesi konseptini tanıttı .

2022'ye hızlıca ilerleyelim. CSS Grid Layout Module 3 spesifikasyonuna eklenmiş CSS Masonry için bir editör taslağımız vardı. Jenn Simmons , CSSWG'nin bunu ilk kamuya açık çalışma taslağı olarak ilerletmesini önerdi . Beş gün sonra, Chromium mühendisi Ian Kilpatrick, CSS Grid Layout modülünün bir parçası olarak işleri ilerletmekle ilgili iki endişeyi dile getirdi , ilki sütun izlerinin boyutlandırılması ve grid'in düzen algoritmasıyla ilgiliydi:

Izgara, her şeyi önceden ızgaraya yerleştirerek ve ardından satırları/sütunları öğelere uyacak şekilde boyutlandırarak çalışır. Duvarcılık temelde bu şekilde çalışmaz çünkü satırları/sütunları önceden boyutlandırmanız gerekir - ardından öğeleri bu satırlara/sütunlara yerleştirmeniz gerekir.

Sonuç olarak, mevcut spesifikasyonun ızgara boyutlandırma mantığını yeniden kullanma biçimi, parçaların içsel olarak boyutlandırılmasında ve ızgaranın kendisi içsel olarak boyutlandırılmışsa (örneğin bir ızgara/esnek/tablo içindeyse, vb.) zayıf sonuçlara yol açar.

İyi nokta! Grid, mevcut alana sığdırmak için boyutlandırmadan önce grid öğelerini önceden yerleştirir. Tekrar ediyorum, masonlukta işleri yönlendiren şey sütunun boyutudur. Mantıksal olarak, şeyleri alana göre yerleştirmek için masonluğu bildirmemiz ve sütun iz boyutlarını önceden yapılandırmamız gerekir. Diğer endişe, görsel ve okuma sırası açısından erişilebilirlikle ilgilidir.

Bu, Jenn'in ilk kamu çalışma taslağı statüsüne yönelik hareketini 2023'ün başlarında durdurdu. Bu yılın Temmuz ayına hızlıca ilerlersek, Ian'ın duvarcılık için alternatif bir yol için puanlarını alırız. Bu, CSS Grid spesifikasyonunu yazan Rachel Andrew dahil olmak üzere her türlü CSS ağır topundan destek aldı .

Ve, bugünden sadece üç hafta önce, fantasai Tab Atkins ile birlikte hazırlanmış alternatif bir teklifin taslağını paylaştı. Bu teklif , göreceğiniz gibi, kendi modülü olarak masonluğa özgüdür.

Ve böylece CSS'de duvarcılık sorununu çözmek için iki rekabet eden önerimiz var.

Duvarcılık ve ızgaranın birleştirilmesi için bir dava

GitHub biletlerinden ve blog yazılarından gelen yorumları topluyoruz…

Flexbox aslında eşyaları bir sıraya koymak ve boş alanı dağıtmak için tasarlanmıştır. Bu yüzden tüm eşyalarınızı bir sıraya koymanın ilk davranışı yapmak isteyebileceğiniz her şey için harika bir başlangıç ​​noktasıdır.  Yapmanız gereken tek şey bu olabilir  . Bir öğretmen olarak eşyaların içine veya dışına nasıl alan ekleyeceğinizi, onları nasıl hizalayacağınızı veya bir sıra yerine bir sütun yapacağınızı öğrenmek zor değildir. Adım adım, varsayılanlardan.

Aynı yaklaşımı . ile de uygulayabilmek istiyorum  display: masonry.

[…]

Önceden var olan başlangıç ​​değerleri nedeniyle bunu grid ile kolayca yapamayız. Grid için iyi varsayılanlar masonry için pek işe yaramıyor. Şu anda şunları yapmanız gerekir:

1. display: gridTek sütunlu bir ızgara düzeni elde etmek için , ekleyin  .
2. Ekle  grid-template-columns: <track-listing>ve şu anda boyutlandırılmış parçaları otomatik olarak doldurmanın bir yolu yok,  auto bu yüzden kaç tane olacağına karar vermeniz gerekecek.  grid-template-columns: repeat(3, auto)Örneğin, kullanarak.
3. Eklemek  grid-template-rows: masonry.
4. Bunun yerine satırları tanımlamak mı istiyorsunuz?  masonry Uygulanacak değeri   değiştirin grid-template-columns ve şimdi satırlarınızı tanımlayın. Bir kez daha, satırları açıkça tanımlamanız gerekir.

Rachel Andrew,“ Masonluk ve iyi varsayılanlar”

Değerli olan şey için, Rachel en azından 2020'den beri bu bayrağı sallıyor . Temel işlevselliği çözen varsayılan yapılandırmaların ergonomisi display: masonryaçık ve ikna edici. Varsayılan davranış, özelliğin amacına uymalı ve ızgara, bir duvar düzenine atlamak için harika bir varsayılan yapılandırma kümesi değildir. Rachel'ın söylemek istediği, duvar davranışını anlamak için ızgarayı öğretmek ve öğrenmenin, iki farklı biçimlendirme bağlamını gereksiz yere tek bir şeye dönüştürmesi ve bunun kafa karışıklığına yol açması. Bunu çürütmeyi zor buluyorum, çünkü buna bir öğretim perspektifinden yaklaşıyorum. Bu şekilde görüldüğünde, özellikleri birleştirmenin ön uç geliştirmeye başka bir kayıp giriş noktası olduğunu söyleyebiliriz .

Son yıllarda, duvar örgüsü düzenlerini gerçekleştirmek için kullandığımız iki temel yöntem şunlardır:

• flex-basis Tutarlı satır boyutları için Flexbox. Öğenin toplam satır genişliğinin beklenen yüzdesine göre ayarlarız  .
• Tutarlı sütun boyutları için ızgara. Satır aralığını, görüntüler için sunucu tarafı veya dinamik içerik için istemci tarafı olmak üzere, içeriğin beklenen en boy oranına göre ayarlıyoruz.

Benim kişisel olarak gözlemlediğim şu:

• Hiçbiri, duvarcılık için bir başlangıç ​​noktası olarak diğerinden daha sezgisel hissettirmiyor. Bu yüzden Grid'i bir temel olarak seçmek biraz can sıkıcı geliyor.
• flex-wrap İnsanlara Flexbox ile Grid'i ne zaman kullanacaklarını öğretirken bazı anlaşmazlıklar yaşansa da, katkıda bulunanların davranışı önemli ölçüde değiştiren özellikleri (örneğin veya  ) kavraması çok daha büyük bir adımdır  grid-auto-flow: dense.

Tyler Sticka, GitHub Sorunu #9041 hakkında yorum yapıyor

Doğru! Masonry için başlangıç ​​noktası olarak flexbox veya grid'i seçmek zorunda kalsaydım (ve her iki şekilde de seçeceğimi sanmıyorum), esnek öğeleri bir sütunda hizalamanın varsayılan davranışı için flexbox'a yönelebilirdim.

Masonry düzenini yönlendirecek CSS'nin sözdizimi ve semantiği, kullanıcı aracıları tarafından uygulamada dahili olarak alt ızgaralar dahil olmak üzere ızgaralar için mevcut mekaniğin parçalarını yeniden kullanabilen gerçek düzen mekaniğinden ayrı bir endişedir. Masonry'nin ızgaranın içine yerleştirildiği veya ızgaranın duvarın içine yerleştirildiği durumlarda, ikisi arasındaki ilişki açıkça belirtilebilir.

@jgotten, GitHub Sorunu #9041 hakkında yorum yapıyor

Yine Rachel, bu sefer Chrome ekibi adına konuşuyor :

Duvar örgüsünün, ızgara düzeni dışında daha iyi tanımlandığını düşünmemizin iki ilgili nedeni vardır: düzen performansı sorunlarının potansiyeli ve hem duvar örgüsünün hem de ızgaranın, bir düzen yönteminde mantıklı olan ancak diğerinde olmayan özelliklere sahip olmasıdır.

Duvar örgüsünün ızgaradan ayrı tutulmasının gerekçesi

Duvarcılığı ızgara düzenine entegre etmenin (  VAKA 2'de olduğu gibi ) temel faydalarından biri, alt ızgaralar gibi mevcut ızgara özelliklerini kullanma yeteneğidir. Alt ızgaralar, bir ızgara içindeki alt elemanlar arasında tutarlı tasarımlara olanak tanır; bu da birçok duvarcılık düzeninde oldukça arzu edilen bir şeydir. Ayrıca, ızgara düzeninde gelecekte yapılacak geliştirmelerin duvarcılık için de faydalı olacağına ve bunların entegrasyonunu daha da değerli hale getireceğine inanıyorum. Duvarcılığı ızgara düzeninin bir uzantısı olarak ele alarak, geliştiriciler tamamen yeni bir sistem öğrenmelerine gerek kalmadan onu hemen kullanmaya başlayabilirler.

Kokomi, GitHub Sorunu #9041 hakkında yorum yapıyor

Masonluğun grid'den ayrı tutulmasının, grid'in özellik setine erişimle, Masonluğun olabileceği kadar güçlü olmasını engellemesi gerçekten büyük bir utanç olurdu:

display: masonry Ayrı bir odak için yapılan argümanların işlevsellik pahasına potansiyel basitliğe çok fazla odaklandığını düşünüyorum  . Grid'in güçlü özelliklerini hariç tutmak, temel düzenlerden daha fazlasını isteyen veya ihtiyaç duyan geliştiricileri engelleyecektir. Ayrıca, başka bir görüntüleme türü tanıtmak düzen ekosisteminde karışıklığa ve parçalanmaya yol açabilir.

Angel Ponce, GitHub Sorunu #9041 hakkında yorum yapıyor

Ancak Rachel buna karşı çıkıyor .

display:grid'e masonry eklenmesine olan güçlü desteğimi ifade etmek istiyorum. Geleneksel bir grid'e zarif bir şekilde dönüşmesi bence büyük bir avantaj. Ama ayrıca, masonry düzeni bugün Grid düzeninde zaten mümkün (bazı kısıtlamalarla)!

Naman Goel, Angel Ponce, GitHub Sorunu #9041 hakkında yorum yapıyor

Chris, tartışma daha da büyüyüp kızışmadan önce 2020'de ikisini birleştirmeye olan ilgisini hafifçe dile getirdi . Tam olarak çınlayan bir destek değil, daha çok mantıklı olabileceğinin bir kabulü:

Sözdizimini beğeniyorum  grid-template-rows: masonry; çünkü açıkça şunu ilettiğini düşünüyorum:  "Bu satırları ayarlamıyorsunuz. Aslında, artık gerçekten satır bile yok, biz bununla ilgileneceğiz."  Sanırım bu, subgrid'de miras alınacak satır olmadığı anlamına geliyor, bu da mantıklı.

Neredeyiz?

Geri bildirim toplamak. Rachel, Ian ve Tab, sizin ve benim gibi kişilerin düşüncelerimizi çantaya eklemeleri için ortak bir çağrı yayınladı . Bu yazının yazıldığı tarih itibarıyla bu sekiz gün önceydi. Bu yalnızca bir harekete geçme çağrısı değil, aynı zamanda her biri için rekabet eden iki fikir ve değerlendirmenin mükemmel bir genel bakışı. Geri bildiriminizi GitHub Issue #9041'e eklemek isteyeceksiniz .

---

CSS Masonry & CSS Grid başlangıçta DigitalOcean ailesinin bir parçası olan CSS-Tricks'te yayınlanmıştır . Bülteni almalısınız .