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, çoğu geliştiricinin kapsayıcı sorguları için istediği "temel işlev grubu" nedir? 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ı, önceden tanımlanmış bir dizi ayrılma noktası (ör. SM, MD, LG, XL) kullanılarak uygulanmış, mobil öncelikli ilkelere göre standartlaştırılmıştır. Bileşenler varsayılan olarak küçük ekranlarda iyi görüntülenecek şekilde optimize edilmiştir ve ardından stiller, daha büyük ekran genişliklerini desteklemek için koşullu olarak üstlenilir. (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ğil, yerleştirildiği bağlamda bileşenin ne kadar kullanılabilir 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 tanımladıktan sonra, söz konusu bileşenlerin CSS'sindeki her @media kuralını @container kuralıyla değiştirmeniz gerekir. Boyut koşullarını aynı tutabilirsiniz.
CSS'niz halihazırda bir dizi önceden tanımlanmış ayrılma noktası kullanıyorsa bunları tam olarak tanımlandıkları şekilde kullanmaya devam edebilirsiniz. Önceden tanımlanmış ayrılma noktaları kullanmıyorsanız bu noktalar için ad tanımlamanız gerekir (buna daha sonra JavaScript'te başvuracağınız 2. adıma bakın).
Aşağıda, varsayılan olarak tek sütun olan bir .photo-gallery bileşenine ait stillere bir örnek verilmiştir ve daha sonra, stilini MD ve XL ayrılma noktalarında iki ve üç sütun olacak şekilde günceller (sırasıyla):
.photo-gallery {
display: grid;
grid-template-columns: 1fr;
}
/* Styles for the `MD` breakpoint */
@media (min-width: 768px) {
.photo-gallery {
grid-template-columns: 1fr 1fr;
}
}
/* Styles for the `XL` breakpoint */
@media (min-width: 1280px) {
.photo-gallery {
grid-template-columns: 1fr 1fr 1fr;
}
}
Bu bileşen stillerini @media kurallarını kullanmaktan @container kurallarını kullanacak şekilde değiştirmek için kodunuzda bul ve değiştir işlevini kullanın:
/* Before: */
@media (min-width: 768px) { /* ... */ }
@media (min-width: 1280px) { /* ... */ }
/* After: */
@container (min-width: 768px) { /* ... */ }
@container (min-width: 1280px) { /* ... */ }
@media kurallarından bileşen stillerinizi ayrılma noktası tabanlı @container kurallarına güncelledikten sonra, sıradaki 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 containers .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 as needed based on your site's design.
const defaultBreakpoints = {SM: 512, MD: 768, LG: 1024, XL: 1280};
// 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 768 ile 1024 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='{"bp1":500,"bp2":1000,"bp3":1500}'>
</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: 768px) {
.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: 1280px) {
.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': 512px,
'MD': 576px,
'LG': 1024px,
'XL': 1280px,
);
@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
@mediakurallarını@containerkuralları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ı.
Yedek stillerin nasıl tanımlandığını görmek için GitHub'da tam demo kaynak koduna göz atabilir ve ö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`);
// ...
}
}
Böylece, bu değerleri JavaScript'ten CSS'ye etkili bir şekilde "aktarabilir", ve böylece CSS'nin tam gücüne (örneğin, calc(), min(), max(), clamp()) sahip olursunuz. Böylece, bu değerleri gerektiği şekilde değiştirebilirsiniz.
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 bazı bileşenler için varsayılan düzeni veya "mobil" düzeni görürler. Bu, dünyanın sonu da değildir.
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.