<picture> öğesi, hiçbir şeyi kendi başına oluşturmaz. Bunun yerine, içteki <img> öğesi için bir karar motoru olarak işlev görür ve ne oluşturulacağına karar verir. <picture>, <audio> ve <video> öğeleri tarafından önceden ayarlanmış bir emsali takip eder: bağımsız <source> öğeleri içeren bir sarmalayıcı öğesi.
<picture>
<source …>
<source …>
<img …>
</picture …>
Bu iç <img>, duyarlı resimleri desteklemeyen eski tarayıcılar için de güvenilir bir yedek desen sağlar: <picture> öğesi kullanıcının tarayıcısı tarafından tanınmazsa yoksayılır. Daha sonra <source> öğeleri de silinir. Çünkü tarayıcı bunları hiç tanımaz veya <video> ya da <audio> üst öğesi olmadan bunlar için anlamlı bir bağlama sahip olmaz.
Ancak iç <img> öğesi tüm tarayıcılar tarafından tanınır ve öğenin src politikasında belirtilen kaynak beklendiği gibi oluşturulur.
<picture> ile "Sanatçı" resimleri
Sayfadaki resmin boyutuna göre bir resmin içeriğinde veya en boy oranında değişiklik yapmaya genellikle "sanatçıya yönelik" duyarlı resim adı verilir. srcset ve sizes, kaynakları kullanıcının tarayıcısının belirlediği şekilde sorunsuzca değiştirerek görünmez bir şekilde çalışacak şekilde tasarlanmıştır.
Ancak zaman zaman, tıpkı sayfa düzenlerini uyarladığınız şekilde, ayrılma noktalarındaki kaynakları değiştirmek isteyebilirsiniz.
Örneğin: Merkezi küçük bir odağı olan tam genişlikte bir üstbilgi resmi, büyük bir görüntü alanında iyi sonuç verebilir:
Ancak, ölçeği küçük görüntü alanlarına uyacak şekilde küçültüldüğünde, resmin merkezi odağı kaybolabilir:
Bu resim kaynaklarının konusu aynıdır ancak bu konuya görsel olarak daha iyi odaklanmak için resim kaynağı oranlarının, ayrılma noktaları arasında değişmesini istersiniz. Örneğin, resmin ortasının daha sıkı yakınlaştırması ve kenarlardaki bazı ayrıntıların kırpılması:
Bu tür bir "kırpma" işlemi, CSS aracılığıyla gerçekleştirilebilir, ancak kullanıcının söz konusu resmi asla göremese bile söz konusu resmi oluşturan tüm verileri istemesine neden olur.
Her source öğesinde, söz konusu source öğesinin seçilmesine yönelik koşulları tanımlayan özellikler bulunur: medya sorgusunu kabul eden media ve bir medya türünü (önceden "MIME türü" olarak bilinir) kabul eden type. Kullanıcının mevcut göz atma bağlamıyla eşleşmesi için kaynak sıradaki ilk <source> seçilir ve bu source üzerindeki srcset özelliğinin içeriği, bu bağlam için doğru adayları belirlemek amacıyla kullanılır. Bu örnekte, kullanıcının görüntü alanı boyutuyla eşleşen media özelliğine sahip ilk source seçili olur:
<picture>
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
<img src="close-crop.jpg" alt="…">
</picture>
İç img değerini her zaman sırayla son olarak belirtmelisiniz. source öğelerinden hiçbiri media veya type ölçütleriyle eşleşmiyorsa resim "varsayılan" kaynak olarak kullanılır. min-width medya sorgusu kullanıyorsanız önceki kodda görüldüğü gibi önce en büyük kaynaklara sahip olmanız gerekir. max-width medya sorgularını kullanırken en küçük kaynağı ilk sıraya koymanız gerekir.
<picture>
<source media="(max-width: 400px)" srcset="mid-bp.jpg">
<source media="(max-width: 800px)" srcset="high-bp.jpg">
<img src="highest-bp.jpg" alt="…">
</picture>
Bir kaynak, belirttiğiniz ölçütlere göre seçildiğinde source öğesindeki srcset özelliği, <img> üzerinde tanımlanmış gibi <img> öğesine iletilir. Bu sayede, sanata yönelik resim kaynaklarını optimize etmek için sizes kullanabilirsiniz.
<picture>
<source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
<source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
<img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>
Elbette, seçilen <source> öğesine göre değişebilen oranları değişebilen bir resim performans sorunu ortaya çıkarır:
<img> yalnızca tek bir width ve height özelliğini destekler ancak bu özelliklerin atlanması, ölçülebilir şekilde daha kötü bir kullanıcı deneyimine yol açabilir.
Bunu açıklayabilmek için, HTML spesifikasyonuna nispeten yeni ancak iyi desteklenen bir ekleme, <source> öğelerinde height ve width özelliklerinin kullanılmasına olanak tanır. Bu araçlar, <img> ürününde olduğu gibi düzen kaymalarını da azaltır ve düzeninizde seçilen <source> öğesi için uygun alan ayrılır.
<picture>
<source
media="(min-width: 800px)"
srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
width="1600"
height="800">
<img src="fallback.jpg"
srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
sizes="calc(100vw - 2em)"
width="1200"
height="750"
alt="…">
</picture>
Resim yönünün, görüntü alanı boyutuna bağlı olan kararlardan daha fazlası için kullanılabileceğini unutmamak gerekir. Çünkü bu durumların çoğu srcset/sizes ile daha verimli bir şekilde ele alınabilir. Örneğin, kullanıcının tercihi tarafından belirtilen renk şemasına daha uygun bir resim kaynağı seçilir:
<picture>
<source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
<img srcset="hero-light.jpg">
</picture>
type özelliği
type özelliği, resim biçimlerini yalnızca destekleyen tarayıcılara sunmak için <picture> öğesinin tekli istek karar motorunu kullanmanıza olanak tanır.
Resim Biçimleri ve Sıkıştırma bölümünde öğrendiğiniz gibi, tarayıcının ayrıştıramadığı bir kodlama, resim verisi olarak bile tanınamaz.
<picture> öğesi kullanıma sunulmadan önce, yeni resim biçimlerini sunmak için en uygun kullanıcı arabirimi çözümleri, tarayıcının bir resim dosyasını kaldırıp bir yedek yükleyip yüklemeyeceğini belirlemeden önce bir resim dosyası için istekte bulunup bu dosyayı ayrıştırmayı denemesini gerektiriyordu. Aşağıdakilere benzer bir komut dosyası örnek olarak verilebilir:
<img src="image.webp"
data-fallback="image.jpg"
onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
alt="...">
Bu kalıpta, her tarayıcıda yine image.webp isteği yapılır. Bu da WebP desteği olmayan tarayıcılar için boşa giden bir aktarım olacağı anlamına gelir. Daha sonra WebP kodlamasını ayrıştıramayan tarayıcılar onerror etkinliği oluşturur ve data-fallback değerini src ile değiştirir. Bu, israfa yol açan bir çözümdü, ancak yine de, ön uçta sunulan tek seçenek bunun gibi yaklaşımlardı. Tarayıcının, herhangi bir özel komut dosyası çalışma (veya ayrıştırılabilme) olasılığı olmadan önce resim isteğinde bulunmaya başladığını ve bu nedenle, bu işlemi önleyemediğimizi unutmayın.
<picture> öğesi, bu gereksiz istekleri önlemek için açıkça tasarlanmıştır. Tarayıcının desteklemediği bir biçimi istemeden tanıması hâlâ mümkün olmasa da type özelliği, tarayıcıyı kaynak kodlamaları konusunda önceden uyarır ve istekte bulunup bulunmamaya karar verebilir.
type özelliğinde, her bir <source> öğesinin srcset özelliğinde belirtilen resim kaynağının Medya Türünü (eski adıyla MIME türü) sağlarsınız. Bu, tarayıcıya, söz konusu source tarafından sağlanan resim adayının herhangi bir harici istek yapılmadan kodunun çözülüp çözülmediğini hemen belirlemesi için gereken tüm bilgileri sağlar. Medya türü tanınmazsa <source> ve tüm adayları dikkate alınmaz ve tarayıcı çalışmaya devam eder.
<picture>
<source type="image/webp" srcset="pic.webp">
<img src="pic.jpg" alt="...">
</picture>
Burada WebP kodlamasını destekleyen tüm tarayıcılar, <source> öğesinin type özelliğinde belirtilen image/webp Medya Türünü tanır, <source> öğesini seçer ve srcset içinde yalnızca tek bir aday sağladığımız için içteki <img> öğesini pic.webp isteğinde bulunma, aktarma ve oluşturma konusunda öğretir. WebP desteği olmayan tarayıcılar source etiketini yok sayar ve bunun tersine herhangi bir talimat olmazsa <img>, src içeriğini 1992'den beri yaptığı gibi oluşturur.
Burada type="image/jpeg" ile ikinci bir <source> öğesi belirtmenize gerek yoktur. JPEG için evrensel bir destek olduğunu varsayabilirsiniz.
Kullanıcının göz atma bağlamı ne olursa olsun, tüm bunlar tek bir dosya aktarımıyla gerçekleştirilir. Ayrıca, oluşturulamayan resim kaynakları için bant genişliği harcanmaz. Bu bir de ileriye dönük bir görüştür: Yeni ve daha verimli dosya biçimleri kendi Medya Türleri ile birlikte gelir ve picture sayesinde bunlardan yararlanabileceğiz. JavaScript'i, sunucu tarafı bağımlılığı olmayan ve <img> ürününün tüm hızında bu olanaklardan yararlanabileceğiz.
Duyarlı resimlerin geleceği
Burada tartışılan tüm işaretleme kalıpları, standartlaştırma açısından ağır bir yük teşkil ediyordu: <img>, yerleşmiş ve web'in merkezinde yer alan bir şeyin işlevselliğini değiştirmek kolay iş değildi. Bu değişikliklerin çözmeyi hedeflediği sorunlar, en azından bir kısmını ifade edecek kadar büyüktü. Bu işaretleme kalıplarıyla iyileştirilebilecek çok şey
olduğunu düşünüp düşünmediğinizi fark ettiyseniz kesinlikle haklısınız. En başından itibaren bu standartların, gelecekteki teknolojiler için bir temel oluşturması amaçlanıyordu.
Bu çözümlerin tamamı mutlaka işaretlemeye dayalı olmuştur. Dolayısıyla, sunucudan gelen ilk yüke dahil edilir ve tarayıcının resim kaynaklarını istemesi için zamanında gelir. Bu, kabul edilemez sizes özelliğine neden olan bir sınırlamadır.
Ancak bu özellikler web platformunda kullanıma sunulduğundan, görüntü isteklerini ertelemenin yerel bir yöntemi de kullanıma sunulmuştur.
Sayfanın düzeni öğrenilene kadar loading="lazy" özelliğine sahip <img> öğeleri istenmez. Bu şekilde, kullanıcının ilk görüntü alanının dışındaki resimlere ilişkin istekler, sayfanın oluşturulması işleminin sonraki aşamalarına kadar ertelenir. Böylece gereksiz istekler önlenebilir. Tarayıcı, bu istekler gönderildiği sırada sayfa düzenini tam olarak anladığı için, bu gibi durumlarda manuel olarak yazılan sizes özelliklerini zahmetten korumak amacıyla HTML spesifikasyonuna ek olarak sizes="auto" özelliği önerilmiştir.
Ufuk doğrultusunda <picture> öğesine de eklemeler yapılarak, sayfa düzeninin stilini belirleme yöntemimiz bazı son derece heyecan verici değişikliklere uyum sağlayacaktır. Görüntü alanı bilgileri üst düzey düzen kararları için sağlam bir temel olsa da geliştirme için tamamen bileşen düzeyinde bir yaklaşım benimsememizi engeller. Bu, bileşenin kapladığı alana yanıt veren stillerle, sayfa düzeninin herhangi bir bölümüne bırakılabilecek bir bileşen gibidir. Bu endişe, kapsayıcı sorgularının ortaya çıkmasına yol açtı. Bu, öğeleri yalnızca görüntü alanına değil, üst kapsayıcılarının boyutuna dayalı olarak şekillendiren bir yöntemdi.
Kapsayıcı sorgu söz diziminin dengeli olmasına ve tarayıcı desteği çok sınırlı olmasına rağmen, yazma sırasında tarayıcı desteği çok sınırlı olsa da, <picture> öğesine aynı şeyi yapma anlamını da sağlar: görüntü alanının boyutuna göre değil, <picture> öğesinin <img> öğesinin kapladığı alana göre <source> seçim ölçütünün kullanılmasına olanak tanıyan potansiyel bir container özelliği.
Bu size biraz belirsiz geliyorsa bunun iyi bir nedeni var: Bu web standartları tartışmaları devam ediyor, ancak henüz bir sonuca varmamış, bu tartışmaları henüz kullanamazsınız.
Duyarlı resim işaretleme, tüm web teknolojileri gibi zaman içinde daha kolay çalışabilme vaadinde bulunsa da, bu işaretlemeyi el yazısıyla yazma yükünü hafifletmeye yardımcı olacak çeşitli hizmetler, teknolojiler ve çerçeveler mevcuttur. Sonraki modülde resim biçimleri, sıkıştırma ve duyarlı resimler hakkında öğrendiğimiz her şeyi modern bir geliştirme iş akışına nasıl entegre edebileceğimizi göreceğiz.