Kısa süre önce Chris Coyier şu soruyu içeren bir blog yayını yazdı:
Artık kapsayıcı sorguları tüm tarayıcı motorlarında desteklendiğine göre neden daha fazla geliştirici bunları kullanmıyor?
Can'ın yayını, birçok olası nedeni listeliyor (örneğin, farkındalık eksikliği, eski alışkanlıkların ağırlaşması) ancak bunun belirli bir nedeni var.
Bazı geliştiriciler şu anda kapsayıcı sorgularını kullanmak istediklerini belirtse de eski tarayıcıları desteklemeleri gerektiğinden bunu kullanamayacaklarını düşünmektedir.
Başlıktan da tahmin edebileceğiniz gibi, eski tarayıcıları desteklemek zorunda olsanız bile çoğu geliştiricinin kapsayıcı sorgularını artık üretimde kullanabileceğini düşünüyoruz. Bu gönderide, önerdiğimiz yaklaşımla ilgili yol gösterilmektedir.
Pragmatik yaklaşım
Şu anda kodunuzda kapsayıcı sorguları kullanmak istiyor ancak deneyimin tüm tarayıcılarda aynı görünmesini istiyorsanız kapsayıcı sorgularını desteklemeyen tarayıcılar için JavaScript tabanlı bir yedek uygulayabilirsiniz.
Bunun ardından şu soru ortaya çıkar: Yedek ne kadar kapsamlı olmalı?
Her yedek oyunda olduğu gibi burada da kullanışlılık ile performans arasında iyi bir denge kurmak gerekiyor. CSS özellikleri için tam API'nin desteklenmesi genellikle mümkün değildir (çoklu dolgu kullanmamanın nedenlerine bakın). Bununla birlikte, çoğu geliştiricinin kullanmak istediği temel işlev grubunu tanımlayarak ve ardından yedeği yalnızca bu özellikler için optimize ederek oldukça yol katedebilirsiniz.
Peki "temel işlevsellik grubu" ne kadar önemli? Bu soruyu yanıtlamak için, çoğu geliştiricinin şu anda medya sorguları içeren duyarlı siteleri nasıl oluşturduğunu düşünün.
Hemen hemen tüm modern tasarım sistemleri ve bileşen kitaplıkları, mobil öncelikli prensiplere göre standartlaştırılmış ve önceden tanımlanmış bir dizi ayrılma noktası (ör. SM
, MD
, LG
, XL
) kullanılarak uygulanmıştır. Bileşenler, varsayılan olarak küçük ekranlarda iyi görüntülenecek şekilde optimize edilmiştir. Ardından stiller, daha büyük ekran genişliklerini içeren sabit bir grubu desteklemek için koşullu olarak katmanlandırılır. (Bunun örnekleri için Bootstrap ve Tailwind dokümanlarına bakın.)
Bu yaklaşım, görüntü alanı tabanlı tasarım sistemleri kadar kapsayıcı tabanlı tasarım sistemleri için de geçerlidir. Çünkü çoğu durumda tasarımcılar için önemli olan, ekranın veya görüntü alanının ne kadar büyük olduğu değildir; bileşenin yerleştirildiği bağlamda kendisine ne kadar alan olduğudur. Başka bir deyişle, ayrılma noktaları tüm görüntü alanına göre (ve tüm sayfa için geçerli) olmak yerine, ayrılma noktaları kenar çubukları, kalıcı iletişim kutuları veya yayın gövdeleri gibi belirli içerik alanlarına uygulanır.
Mobil öncelikli, ayrılma noktası tabanlı (şu anda çoğu geliştiricinin de yaptığı) bir yaklaşımın kısıtlamaları dahilinde çalışabiliyorsanız bu yaklaşım için container tabanlı bir yedek uygulamak, her bir container sorgu özelliğine tam destek uygulamaya kıyasla çok daha kolay olacaktır.
Sonraki bölümde, tüm bunların nasıl çalıştığı ve bunu mevcut bir siteye nasıl uygulayacağınızı gösteren adım adım açıklamalı bir kılavuz yer almaktadır.
İşleyiş şekli
1. Adım: Bileşen stillerinizi, @media
kural yerine @container
kurallarını kullanacak şekilde güncelleyin
Bu ilk adımda, sitenizde görüntü alanına dayalı boyutlandırma yerine kapsayıcı tabanlı boyutlandırmanın fayda sağlayacağını düşündüğünüz bileşenleri belirleyin.
Bu stratejinin nasıl çalıştığını görmek için sadece bir veya iki bileşenle başlamak iyi bir fikirdir, ancak bileşenlerinizin% 100'ünü kapsayıcı tabanlı stile dönüştürmek isterseniz sorun değil. Bu stratejinin en iyi tarafı, gerekirse onu adım adım uygulayabilmenizdir.
Güncellemek istediğiniz bileşenleri belirledikten sonra bu bileşenlerdeki her @media
kuralını değiştirmeniz gerekir. CSS'den bir @container
kuralına.
Aşağıda, bunun varsayılan olarak tek sütun olan ve ardından düzenini MD ve XL ayrılma noktalarında iki ve üç sütun olacak şekilde güncellemek için @media
kurallarını kullanan (sırasıyla) bir .photo-gallery
bileşeninde nasıl görünebileceğine dair bir örnek verilmiştir:
.photo-gallery {
display: grid;
grid-template-columns: 1fr;
}
/* Styles for the `MD` breakpoint */
@media (min-width: 800px) {
.photo-gallery {
grid-template-columns: 1fr 1fr;
}
}
/* Styles for the `XL` breakpoint */
@media (min-width: 1200px) {
.photo-gallery {
grid-template-columns: 1fr 1fr 1fr;
}
}
.photo-gallery
bileşenini @container
kurallarını kullanacak şekilde güncellemek için önce @media
dizesini CSS'de @container
dizesiyle değiştirin. Bu iki kuralın dil bilgisi, birçok durumda değiştirmeniz gereken tek şey olabileceği kadar benzerdir.
Sitenizin tasarımına bağlı olarak, özellikle sitenizin @media
kuralları, çeşitli görüntü alanı boyutlarındaki belirli bileşenler için ne kadar alan olacağına ilişkin belirli varsayımlarda bulunuyorsa boyut koşulunu da güncellemeniz gerekebilir.
Örneğin, önceki örnekteki MD
ve XL
ayrılma noktalarındaki .photo-gallery
CSS stilleri bu ayrılma noktalarında 200 piksel genişliğinde bir kenar çubuğunun görüntüleneceğini varsayarsa @container
kurallarının boyut koşullarının yaklaşık 200 piksel daha az olması gerekir ("kapsayıcının" öğesi, kenar çubuğunu içermez..photo-gallery
Toplamda, .photo-gallery
CSS'sini @media
kurallarından @container
kurallarına dönüştürmek için değişikliklerin tamamı aşağıdaki gibidir:
/* Before, using the original breakpoint sizes: */
@media (min-width: 800px) { /* ... */ }
@media (min-width: 1200px) { /* ... */ }
/* After, with the breakpoint sizes reduced by 200px: */
@container (min-width: 600px) { /* ... */ }
@container (min-width: 1000px) { /* ... */ }
Bildirim bloğu içindeki stillerden hiçbirini değiştirmeniz gerekmez. Çünkü bu stiller, belirli stillerin ne zaman uygulanması gerektiğini değil, bileşenin nasıl göründüğünü yansıtır.
Bileşen stillerinizi @media
kurallarından @container
kurallarına güncelledikten sonraki adım, kapsayıcı öğelerinizi yapılandırmaktır.
2. Adım: HTML'nize kapsayıcı öğeleri ekleyin
Önceki adımda, bir kapsayıcı öğesinin boyutuna göre bileşen stilleri tanımlanıyordu. Sonraki adım, sayfanızdaki hangi öğelerin, @container
kurallarının boyutuna göre olacağı kapsayıcı öğeler olması gerektiğini tanımlamaktır.
container-type
özelliğini size
veya inline-size
olarak ayarlayarak herhangi bir öğeyi CSS'de kapsayıcı öğe olarak tanımlayabilirsiniz. Kapsayıcı kurallarınız genişliğe dayalıysa, genellikle inline-size
kullanmanızı öneririz.
Aşağıdaki temel HTML yapısına sahip bir site düşünün:
<body>
<div class="sidebar">...</div>
<div class="content">...</div>
</body>
Bu site kapsayıcılarında .sidebar
ve .content
öğelerini oluşturmak için şu kuralı CSS'nize ekleyin:
.content, .sidebar {
container-type: inline-size;
}
Kapsayıcı sorgularını destekleyen tarayıcılarda, önceki adımda tanımlanan bileşen stillerini, hangi öğenin içinde olduklarına bağlı olarak ana içerik alanına veya kenar çubuğuna göre oluşturmak için ihtiyacınız olan tek şey bu CSS'dir.
Ancak, kapsayıcı sorgularını desteklemeyen tarayıcılar için yapılacak bazı ek işlemler vardır.
Kapsayıcı öğelerinin boyutunun ne zaman değiştiğini algılayan ve ardından DOM'yi bu değişikliklere dayanarak CSS'nizin yararlanabileceği şekilde güncelleyen bir kod eklemeniz gerekir.
Neyse ki bunu yapmak için gereken kod minimum düzeydedir ve herhangi bir sitede ya da içerik alanında kullanabileceğiniz paylaşılan bir bileşene tamamen soyutlanabilir.
Aşağıdaki kod, boyut değişikliklerini otomatik olarak dinleyen ve CSS'nizin aşağıdakilere göre biçimlendirebileceği ayrılma noktası sınıflarını ekleyen, yeniden kullanılabilir bir <responsive-container>
öğesini tanımlar:
// A mapping of default breakpoint class names and min-width sizes.
// Redefine these (or add more) as needed based on your site's design.
const defaultBreakpoints = {SM: 400, MD: 600 LG: 800, XL: 1000};
// A resize observer that monitors size changes to all <responsive-container>
// elements and calls their `updateBreakpoints()` method with the updated size.
const ro = new ResizeObserver((entries) => {
entries.forEach((e) => e.target.updateBreakpoints(e.contentRect));
});
class ResponsiveContainer extends HTMLElement {
connectedCallback() {
const bps = this.getAttribute('breakpoints');
this.breakpoints = bps ? JSON.parse(bps) : defaultBreakpoints;
this.name = this.getAttribute('name') || '';
ro.observe(this);
}
disconnectedCallback() {
ro.unobserve(this);
}
updateBreakpoints(contentRect) {
for (const bp of Object.keys(this.breakpoints)) {
const minWidth = this.breakpoints[bp];
const className = this.name ? `${this.name}-${bp}` : bp;
this.classList.toggle(className, contentRect.width >= minWidth);
}
}
}
self.customElements.define('responsive-container', ResponsiveContainer);
Bu kod, DOM'deki herhangi bir <responsive-container>
öğesinde yapılan boyut değişikliklerini otomatik olarak dinleyen bir ResizeObserver oluşturarak çalışır. Boyut değişikliği, tanımlanan ayrılma noktası boyutlarından biriyle eşleşirse bu ayrılma noktası adına sahip sınıf öğeye eklenir (ve koşul artık eşleşmiyorsa kaldırılır).
Örneğin, <responsive-container>
öğesinin width
değeri 600 ile 800 piksel arasındaysa (kodda ayarlanan varsayılan ayrılma noktası değerlerine göre) SM
ve MD
sınıfları şu şekilde eklenir:
<responsive-container class="SM MD">...</responsive-container>
Bu sınıflar, kapsayıcı sorgularını desteklemeyen tarayıcılar için yedek stiller tanımlamanıza olanak tanır (3. adım: CSS'nize yedek stiller ekleme bölümüne bakın).
Önceki HTML kodunu bu kapsayıcı öğesini kullanacak şekilde güncellemek için kenar çubuğu ve ana içerik <div>
öğelerini <responsive-container>
öğeleri olacak şekilde değiştirin:
<body>
<responsive-container class="sidebar">...</responsive-container>
<responsive-container class="content">...</responsive-container>
</body>
Çoğu durumda <responsive-container>
öğesini herhangi bir özelleştirme olmadan kullanabilirsiniz. Ancak özelleştirmeniz gerekirse aşağıdaki seçeneklerden yararlanabilirsiniz:
- Özel ayrılma noktası boyutları: Bu kod, bir dizi varsayılan ayrılma noktası sınıf adını ve minimum genişlik boyutunu kullanır, ancak bu varsayılanları istediğiniz gibi değiştirirsiniz. Ayrıca,
breakpoints
özelliğini kullanarak bu değerleri öğe bazında geçersiz kılabilirsiniz. - Adlandırılmış kapsayıcılar: Bu kod,
name
özelliğini ileterek adlandırılmış kapsayıcıları da destekler. Kapsayıcı öğeleri iç içe yerleştirmeniz gerekiyorsa bu önemli olabilir. Daha fazla bilgi edinmek için sınırlamalar bölümünü inceleyin.
Bu iki yapılandırma seçeneğini ayarlayan bir örneği aşağıda bulabilirsiniz:
<responsive-container
name='sidebar'
breakpoints='{"bp4":400,"bp5":500,"bp6":600,"bp7":700,"bp8":800,"bp9":900,"bp10":1000}'>
</responsive-container>
Son olarak, bu kodu gruplarken kodu yalnızca tarayıcı kapsayıcı sorgularını desteklemiyorsa yüklemek için özellik algılama ve dinamik import()
özelliklerini kullandığınızdan emin olun.
if (!CSS.supports('container-type: inline-size')) {
import('./path/to/responsive-container.js');
}
3. Adım: CSS'nize yedek stiller ekleyin
Bu stratejinin son adımı, @container
kurallarında tanımlanan stilleri tanımayan tarayıcılar için yedek stiller eklemektir. Bu işlemi, <responsive-container>
öğelerinde ayarlanan ayrılma noktası sınıflarını kullanarak bu kuralları kopyalayarak yapabilirsiniz.
Önceki .photo-gallery
örneğinden devam edersek iki @container
kuralının yedek stilleri şöyle görünebilir:
/* Container query styles for the `MD` breakpoint. */
@container (min-width: 600px) {
.photo-gallery {
grid-template-columns: 1fr 1fr;
}
}
/* Fallback styles for the `MD` breakpoint. */
@supports not (container-type: inline-size) {
:where(responsive-container.MD) .photo-gallery {
grid-template-columns: 1fr 1fr;
}
}
/* Container query styles for the `XL` breakpoint. */
@container (min-width: 1000px) {
.photo-gallery {
grid-template-columns: 1fr 1fr 1fr;
}
}
/* Fallback styles for the `XL` breakpoint. */
@supports not (container-type: inline-size) {
:where(responsive-container.XL) .photo-gallery {
grid-template-columns: 1fr 1fr 1fr;
}
}
Bu kodda, her bir @container
kuralı için karşılık gelen ayrılma noktası sınıfı mevcutsa <responsive-container>
öğesiyle koşullu olarak eşleşen bir eşdeğer kural bulunur.
Seçicinin <responsive-container>
öğesiyle eşleşen kısmı, :where() işlevsel sanal sınıf seçici içine sarmalanır. Böylece, yedek seçicinin özgüllüğü, @container
kuralı içindeki orijinal seçicinin belirliliğine eşdeğerdir.
Her yedek kural ayrıca bir @supports
bildirimine sarmalanır. Bu, yedeğin çalışması için kesinlikle gerekli olmasa da, kapsayıcı sorgularını destekliyorsa tarayıcı bu kuralları tamamen yok sayar ve bu da genel olarak stil eşleştirme performansını iyileştirebilir. Ayrıca, tarayıcının kapsayıcı sorgularını desteklediğini ve bu yedek stillere ihtiyaç duymadığını bildikleri takdirde derleme araçlarının veya CDN'lerin bu bildirimleri kaldırmasına da izin verir.
Bu yedek stratejisinin ana dezavantajı, stil beyanını iki kez tekrarlamanızı gerektirmesidir. Bu hem yorucu hem de hatalara açıktır. Bununla birlikte, bir CSS ön işlemcisi kullanıyorsanız bunu soyutlayarak hem @container
kuralını hem de yedek kodu sizin için oluşturan bir karışıma dönüştürebilirsiniz. Aşağıda Sass'in kullanıldığı bir örnek verilmiştir:
@use 'sass:map';
$breakpoints: (
'SM': 400px,
'MD': 600px,
'LG': 800px,
'XL': 1000px,
);
@mixin breakpoint($breakpoint) {
@container (min-width: #{map.get($breakpoints, $breakpoint)}) {
@content();
}
@supports not (container-type: inline-size) {
:where(responsive-container.#{$breakpoint}) & {
@content();
}
}
}
Daha sonra, bu karışımı oluşturduktan sonra, orijinal .photo-gallery
bileşen stillerini aşağıdaki gibi güncelleyebilirsiniz. Bu şekilde yinelemeyi tamamen ortadan kaldırabilirsiniz:
.photo-gallery {
display: grid;
grid-template-columns: 1fr;
@include breakpoint('MD') {
grid-template-columns: 1fr 1fr;
}
@include breakpoint('XL') {
grid-template-columns: 1fr 1fr 1fr;
}
}
Hepsi bu kadar!
Özet
Özetlemek gerekirse, kapsayıcı sorgularını hemen bir tarayıcılar arası yedeğiyle kullanmak için kodunuzu nasıl güncelleyeceğiniz aşağıda anlatılmıştır.
- Kapsayıcılarına göre stilini belirlemek istediğiniz kimlik bileşenleri ve CSS'lerindeki
@media
kurallarını@container
kurallarını kullanacak şekilde güncelleyin. Ayrıca (henüz yapmadıysanız), kapsayıcı kurallarınızdaki boyut koşullarına uygun bir dizi ayrılma noktası adını standartlaştırın. - Özel
<responsive-container>
öğesini destekleyen JavaScript'i ve ardından<responsive-container>
öğesini, sayfanızda bileşenlerinizin göreli olmasını istediğiniz tüm içerik alanlarına ekleyin. - Eski tarayıcıları desteklemek için CSS'nize, HTML'nizdeki
<responsive-container>
öğelerine otomatik olarak eklenen ayrılma noktası sınıflarıyla eşleşen yedek stiller ekleyin. Aynı stilleri iki kez yazmak zorunda kalmamak için ideal olarak bir CSS ön işlemci karması kullanın.
Bu stratejinin en iyi yanı, tek seferlik kurulum maliyeti olmasıdır. Ancak sonrasında yeni bileşenler eklemek ve bu bileşenler için kapsayıcıya göre stiller tanımlamak için ek çaba harcamanız gerekmez.
Uygulamalı olarak görün
Tüm bu adımların birlikte nasıl çalıştığını anlamanın en iyi yolu, muhtemelen uygulamanın nasıl çalıştığının demosunu izlemektir.
Bu demo, 2019'da oluşturulan bir sitenin (kapsayıcı sorguları ortaya çıkmadan önce) güncellenmiş bir sürümüdür. Gerçekten duyarlı bileşen kitaplıkları oluşturmak için kapsayıcı sorgularının neden gerekli olduğunu anlamanıza yardımcı olur.
Bu site bir dizi "duyarlı bileşen" için tanımlanmış stillere sahip olduğundan, burada açıklanan stratejiyi önemsiz bir sitede test etmek için mükemmel bir adaydı. Güncellemenin aslında oldukça kolay olduğu ve orijinal site stillerinde hemen hemen hiçbir değişiklik gerektirmediği ortaya çıktı.
GitHub'da demo kaynak kodunun tamamına göz atabilir ve yedek stillerin nasıl tanımlandığını görmek için özellikle demo bileşeni CSS'sini inceleyebilirsiniz. Yalnızca yedek davranışı test etmek isterseniz kapsayıcı sorgularını destekleyen tarayıcılarda bile bu varyantın tamamını içeren yalnızca yedek bir demodan yararlanabilirsiniz.
Sınırlamalar ve olası iyileştirmeler
Bu gönderinin başında belirtildiği gibi, burada açıklanan strateji, geliştiricilerin kapsayıcı sorgularına ulaşırken önem verdiği kullanım alanlarının çoğunda işe yarar.
Bununla birlikte, bu stratejinin kasıtlı olarak desteklemeye çalışmadığı bazı daha gelişmiş kullanım alanları vardır. Bu örnekleri bir sonraki adımda ele alacağız:
Container sorgu birimleri
Kapsayıcı sorguları spesifikasyonu, her biri kapsayıcının boyutuna bağlı olan bir dizi yeni birimi tanımlar. Bazı durumlarda potansiyel olarak yararlı olsa da, duyarlı tasarımların çoğu, yüzde değerleri veya ızgara ya da esnek düzenler gibi mevcut araçlarla gerçekleştirilebilir.
Bununla birlikte, kapsayıcı sorgu birimlerini kullanmanız gerekiyorsa özel özellikleri kullanarak bunlar için kolayca destek ekleyebilirsiniz. Özellikle, kapsayıcı öğede kullanılan her birim için aşağıdaki gibi bir özel özellik tanımlayarak:
responsive-container {
--cqw: 1cqw;
--cqh: 1cqh;
}
Ve kapsayıcı sorgu birimlerine erişmeniz gerektiğinde, birimin kendisini kullanmak yerine bu özellikleri kullanın:
.photo-gallery {
font-size: calc(10 * var(--cqw));
}
Ardından, eski tarayıcıları desteklemek için bu özel özelliklerin değerlerini ResizeObserver
geri çağırma işleminin içindeki kapsayıcı öğesinde ayarlayın.
class ResponsiveContainer extends HTMLElement {
// ...
updateBreakpoints(contentRect) {
this.style.setProperty('--cqw', `${contentRect.width / 100}px`);
this.style.setProperty('--cqh', `${contentRect.height / 100}px`);
// ...
}
}
Bu sayede, başarılı bir şekilde bu değerleri JavaScript'ten CSS'ye dönüştürür ve gerektiğinde bunları değiştirmek için CSS'nin tam gücüne (örneğin, calc()
, min()
, max()
, clamp()
) sahip olursunuz.
Mantıksal özellikler ve yazma modu desteği
Bu CSS örneklerinden bazılarındaki @container
bildirimlerinde width
yerine inline-size
kullanıldığını fark etmiş olabilirsiniz. Ayrıca yeni cqi
ve cqb
birimlerini (sırasıyla satır içi ve engelleme boyutları için) de fark etmiş olabilirsiniz. Bu yeni özellikler, CSS'nin fiziksel veya yönlendirici özellikler yerine mantıksal özelliklere ve değerlere geçişini yansıtmaktadır.
Maalesef, Dimension Observer gibi API'ler width
ve height
dillerinde değerleri bildirmeye devam ediyor. Dolayısıyla tasarımlarınız mantıksal özelliklerin esnekliğine ihtiyaç duyuyorsa bunu sizin için yapmanız gerekir.
getComputedStyle()
gibi bir kapsayıcı öğesi kullanarak yazma modunu almak mümkün olsa da bunu yapmanın bir maliyeti vardır ve yazma modunun değişip değişmediğini tespit etmenin iyi bir yolu yoktur.
Bu nedenle en iyi yaklaşım, <responsive-container>
öğesinin kendisinin site sahibinin gerektiği şekilde ayarlayabileceği (ve güncelleyebileceği) bir yazma modu özelliğini kabul etmesidir. Bunu uygulamak için önceki bölümde gösterilen yaklaşımın aynısını izlemeniz ve width
ile height
'ı gerektiği şekilde değiştirmeniz gerekir.
İç içe yerleştirilmiş container'lar
container-name
özelliği, bir kapsayıcıya ad vermenize olanak tanır. Bu ad daha sonra bir @container
kuralında referans alınabilir. Adlandırılmış kapsayıcılar, kapsayıcıların içinde iç içe yerleştirilmiş kapsayıcılarınız varsa ve yalnızca belirli kapsayıcılarla (yalnızca en yakın üst öğe kapsayıcıyla değil) eşleşecek belirli kurallara ihtiyacınız varsa kullanışlıdır.
Burada açıklanan yedek stratejisi, belirli ayrılma noktası sınıflarıyla eşleşen öğeleri biçimlendirmek için alt öğe birleştirici kullanır. Birden çok kapsayıcı öğesinin üst öğesine ait herhangi bir sayıda ayrılma noktası sınıfı belirli bir bileşenle aynı anda eşleşebileceğinden, iç içe yerleştirilmiş kapsayıcılarınız varsa bu durum bozulabilir.
Örneğin, burada .photo-gallery
bileşenini sarmalayan iki <responsive-container>
öğesi vardır, ancak dış kapsayıcı iç kapsayıcıdan büyük olduğu için bunlara farklı ayrılma noktası sınıfları eklenmiştir.
<responsive-container class="SM MD LG">
...
<responsive-container class="SM">
...
<div class="photo-gallery">...</div class="photo-gallery">
</responsive-container>
</responsive-container>
Bu örnekte, dış kapsayıcıdaki MD
ve LG
sınıfı, .photo-gallery
bileşeniyle eşleşen stil kurallarını etkiler. .photo-gallery
bileşeniyle eşleşen stil kuralları, kapsayıcı sorgularının davranışıyla eşleşmez (çünkü bunlar yalnızca en yakın üst öğe kapsayıcıyla eşleşir).
Bu sorunu gidermek için:
- İç içe yerleştirdiğiniz tüm kapsayıcıları her zaman adlandırdığınızdan ve çakışmaları önlemek için ayrılma noktası sınıflarınızın önünde bu kapsayıcı adının bulunduğundan emin olun.
- Yedek seçicilerinizde alt birleştirici yerine alt birleştirici'yi kullanın (bu biraz daha sınırlayıcıdır).
Demo sitesinin iç içe yerleştirilmiş kapsayıcılar bölümünde, adlandırılmış kapsayıcıların ve hem adlandırılmış hem de adsız @container
kuralları için yedek stilleri oluşturmak amacıyla kodda kullandığı Sass mix'i ile birlikte bu kapsayıcıların nasıl kullanıldığına dair bir örnek verilmiştir.
:where()
, Özel Öğeler veya Yeniden Boyutlandırma Gözlemcisini desteklemeyen tarayıcılar ne olacak?
Bu API'ler nispeten yeni gibi görünse de hepsi üç yıldan uzun süredir tüm tarayıcılarda desteklenmektedir ve hepsi geniş çapta kullanıma sunulan Temel bölümünün bir parçasıdır.
Dolayısıyla, sitenizi ziyaret edenlerin önemli bir kısmının bu özelliklerden birini desteklemeyen tarayıcılardan olduğunu gösteren verileriniz yoksa, bu özellikleri yedek olmadan kullanmamak için bir neden yoktur.
Böyle bir durumda bile, bu özel kullanım alanında olabilecek en kötü durum, yedeğin kullanıcılarınızın çok küçük bir yüzdesi için çalışmamasıdır. Bu, kapsayıcı boyutu için optimize edilmiş bir görünüm yerine varsayılan görünümü görecekleri anlamına gelir.
Sitenin işlevselliği devam etmelidir ve asıl önemli olan budur.
Neden sadece container sorgusu çoklu dolgusu kullanmıyorsunuz?
CSS özelliklerinin çoklu doldurma işlemi de zordur ve genellikle tarayıcının tüm CSS ayrıştırıcısının ve kademeli mantığının JavaScript'te yeniden uygulanmasını gerektirir. Sonuç olarak, CSS çoklu dolgu yazarları, neredeyse her zaman çeşitli özellik sınırlamaları ve önemli performans yükü içeren birçok ödün vermek zorunda kalırlar.
Bu nedenlerle, Google Chrome Labs'den artık bakımı yapılmayan (ve esasen demo amaçlı olarak tasarlanmış) container-query-polyfill (kapsayıcı-sorgu-polyfill) dahil olmak üzere üretimde genellikle CSS polyfill'lerinin kullanılmasını önermiyoruz.
Burada açıklanan yedek stratejisi daha az sınırlamaya sahiptir, çok daha az kod gerektirir ve herhangi bir kapsayıcı sorgusu çoklu dolgusunun yapabileceğinden çok daha iyi performans gösterir.
Eski tarayıcılar için bir yedek uygulamanız bile gerekiyor mu?
Burada belirtilen sınırlamalardan herhangi biri hakkında endişeleriniz varsa kendinize her şeyden önce gerçekten yedek uygulamanız gerekip gerekmediğini sormanız faydalı olacaktır. Sonuçta, bu sınırlamalardan kaçınmanın en kolay yolu, özelliği herhangi bir yedek olmadan kullanmaktır. Dürüst olmak gerekirse birçok durumda bu son derece makul bir seçim olabilir.
caniuse.com'a göre, kapsayıcı sorguları küresel internet kullanıcılarının% 90'ı tarafından desteklenmektedir. Bu yazıyı okuyan birçok kişi için kapsayıcı sorguları kullanıcı tabanı için oldukça yüksek olabilir. Bu nedenle, kullanıcılarınızın çoğunun kullanıcı arayüzünüzün kapsayıcı sorgu sürümünü göreceğini aklınızda bulundurmanız önemlidir. Bunu yapmayan kullanıcıların% 10'u içinse kötü bir deneyim yaşayacakları anlamına gelmiyor. Bu stratejiyi uygularken en kötü durumda, bu kullanıcılar varsayılanı veya "mobil"i görürler bu dünyanın sonu değil.
Değişiklik yaparken, tüm kullanıcılara tutarlı ancak vaatin altında bir deneyim sunan en düşük ortak paydalı bir yaklaşıma odaklanmak yerine, kullanıcılarınızın çoğunluğu için optimizasyon yapmak iyi bir uygulamadır.
Dolayısıyla, tarayıcı desteği eksikliği nedeniyle kapsayıcı sorgularını kullanamayacağınızı varsaymadan önce, bu sorguları kullanmayı seçerseniz nasıl bir deneyim yaşayacağınızı düşünün. Herhangi bir yedek olmasa bile, bu zahmete değebilir.
Beklenenler
Bu gönderinin, kapsayıcı sorgularını şu anda üretimde kullanabileceğinizi ve desteklenmeyen tarayıcıların tamamen ortadan kalkmasını yıllarca beklemek zorunda kalmayacağınız konusunda sizi ikna ettiğini umuyorum.
Burada özetlenen strateji bir miktar ekstra çalışma gerektirse de çoğu kullanıcının bunu kendi sitesinde uygulayabileceği kadar basit ve anlaşılır olmalıdır. Bununla birlikte, benimsemeyi daha da kolaylaştırmak için elbette kullanılabilecek alan var. Buradaki fikirlerden biri, çok sayıda farklı parçayı, belirli bir çerçeve veya yığın için optimize edilmiş tek bir bileşende toplamak ve bütün bu işleri sizin yerinize halletmek olabilir. Bunun gibi bir şey derlerseniz bize bildirerek tanıtımını yapmanıza yardımcı olabiliriz.
Son olarak, kapsayıcı sorgularının ötesinde, artık tüm önemli tarayıcı motorlarında birlikte çalışabilen pek çok muhteşem CSS ve kullanıcı arayüzü özelliği bulunuyor. Topluluk olarak, kullanıcılarımızın yararlanabilmesi için bu özellikleri nasıl gerçekten kullanabileceğimizi inceleyelim.
Güncelleme (25 Temmuz 2024): Başlangıçta "1. Adım"daki kılavuzu medya sorgularının ve kapsayıcı sorgularının aynı boyut koşullarını kullanabileceğini önerdi. Bu durum çoğu zaman doğrudur ancak her zaman geçerli değildir (bazı nedenlerin doğru belirtildiği gibi). Güncellenen kılavuzda bu soruna açıklık getiriliyor ve boyut koşullarının değişmesi gerekebileceği örnekler sunuluyor.
Güncelleme (2 Temmuz 2024): İlk olarak tüm CSS kod örnekleri Sass kullandı (nihai öneriyle tutarlılık için). Okuyuculardan gelen geri bildirimler doğrultusunda, ilk birkaç CSS düz CSS olarak güncellenmiştir ve Sass yalnızca karmalarının kullanılmasını gerektiren kod örneklerinde kullanılmaktadır.