Konuyu Açan
#1
Bir kartın telefonda tek sütuna düşmesi kolay; asıl mesele aynı kart dar bir yan sütuna girdiğinde de düzgün davranması. Bu yüzden klasik “mobil, tablet, masaüstü” kırılımlarının yanına bileşenin kendi genişliğini dikkate alan tasarım yaklaşımını daha çok konuşmamız gerektiğini düşünüyorum.
Container query’ler burada güzel bir kapı açıyor: Bir ürün kartı, sayfanın tamamından bağımsız olarak bulunduğu alana göre görselini küçültebilir, metni alt alta alabilir ya da ikincil bilgileri gizleyebilir. Böylece aynı bileşen ana sayfada, kenar çubuğunda ve içerik içinde daha az istisnayla kullanılabiliyor.
Ama bunun tasarım sistemlerine etkisi de var. Her bileşenin kendi kurallarını yazmak özgürlük sağlarken, ekip içinde tutarsız davranışlar doğurabilir. Örneğin dar alanda hangi bilgiler saklanmalı? Fiyat mı, açıklama mı, yoksa görsel mi? Bu karar CSS’ten çok içerik hiyerarşisiyle ilgili.
Bence en iyi sonuç, kırılım noktalarını tamamen kaldırmak değil; sayfa düzeyindeki kararlarla bileşen düzeyindeki kararları ayırmak. Siz projelerinizde container query kullanıyor musunuz? Kullanıyorsanız tasarım sisteminizde kuralları nasıl ortaklaştırıyorsunuz?
Container query’ler burada güzel bir kapı açıyor: Bir ürün kartı, sayfanın tamamından bağımsız olarak bulunduğu alana göre görselini küçültebilir, metni alt alta alabilir ya da ikincil bilgileri gizleyebilir. Böylece aynı bileşen ana sayfada, kenar çubuğunda ve içerik içinde daha az istisnayla kullanılabiliyor.
Ama bunun tasarım sistemlerine etkisi de var. Her bileşenin kendi kurallarını yazmak özgürlük sağlarken, ekip içinde tutarsız davranışlar doğurabilir. Örneğin dar alanda hangi bilgiler saklanmalı? Fiyat mı, açıklama mı, yoksa görsel mi? Bu karar CSS’ten çok içerik hiyerarşisiyle ilgili.
Bence en iyi sonuç, kırılım noktalarını tamamen kaldırmak değil; sayfa düzeyindeki kararlarla bileşen düzeyindeki kararları ayırmak. Siz projelerinizde container query kullanıyor musunuz? Kullanıyorsanız tasarım sisteminizde kuralları nasıl ortaklaştırıyorsunuz?