İçerik
İmg etiketiyle karmaşık bir ilişkim var.
İmg etiketinin her zaman kalbimde özel bir yeri olacağını baştan söylemeliyim. Demek istediğim, birlikte çok güzel zamanlarımız oldu. Gifler - oh, hareketli gifler! Ev mobilyalarından düşen kedilerin döngülerini izleyerek nasıl gülerdik.
Yine de işler değişir. Değiştim; web değişti. Daha da önemlisi: kullanıcıların tarama bağlamları kökten değişti. İnsanlar internete şaşırtıcı bir cihaz yelpazesinden erişiyorlar: Ortalama uzay mekiğinden daha fazla bilgi işlem gücüne sahip telefonlar, ultra yüksek çözünürlüklü tabletler ve devasa televizyonlar. Sonuç olarak, çoğumuz hem web'e felsefi yaklaşımlarımız hem de sonuç olarak geliştirdiğimiz teknikler açısından tasarımcılar ve geliştiriciler olarak değiştik. Duyarlı web tasarımı bize belirsizliğin üstesinden gelmek için inanılmaz derecede güçlü bir araç seti sunarak, içeriği kullanıcılara herhangi bir göz atma bağlamı için ısmarlama görünen bir şekilde sunma yolunda büyük adımlar atmamıza olanak tanıyor. Duyarlı web tasarımının küçük bir parçası olmaksızın teşekkür ederiz, yıllardır web'e empoze etmeye çalıştığımız statik genişlikli konfor bölgelerinden (1024px, 960px, 320px vb.) Kaçınmaya başladık ve başladık. başından beri Web'in doğasında var olan esnekliği kucaklamak için.
Yine de img etiketi bizde pek değişmedi. Neyse ki bizim için - ve esnek düzenler için yeni keşfettiğimiz takdir - görüntüler başından beri esnekti. Bir img etiketinden yükseklik ve genişlik niteliklerini kaldırarak ve CSS'mizde maksimum genişliği% 100 olarak ayarlayarak, "bu görüntünün üst kapsayıcısını taşmasını önleyin" diyoruz. Düzenimiz yeniden boyutlandıkça, görsellerimiz de yeniden boyutlandırılır.
İşlerin karmaşıklaştığı nokta şudur: Esnek görüntüleri kullanırken, oynatılan medyanın, mümkün olan en büyük ekranda makul bir şekilde bekleyebileceğimiz boyuta kadar ölçeklenebilecek kadar büyük olmasını sağlamalıyız. Kullanıcılara gerçek bir fayda göremeyecek kadar çok büyük bir masraf getirdik - 2.000 piksel genişliğindeki bir görüntü, 300 piksel genişliğindeki bir ekranda çok büyük, savurgan bir istek anlamına gelir.
Gizli maliyet
Şimdi, bunun şovu durduran bir konu olmadığı iddia edilebilir; "Retina" görüntülerinin ortaya çıkışını da hesaba katarak dolaşmak için bol miktarda bant genişliğimiz olduğunu. Yani, elbette, bir kişinin karşılaştığı en kötü bağlantının ortalama 3G / 4G, gelişmiş ve özellik yüklü bir cihaz kullanmak olduğunu varsayarsak. Bununla birlikte, dünya çapında milyonlarca insan şu anda internete yalnızca mobil bağlantılardan erişiyor, tüketilen her kilobayt için para ödüyor ve özellikli telefonlardan yalnızca biraz daha iyi cihazlar kullanıyor. Büyük görüntülere ayrım gözetmeksizin hizmet vermenin onları kullanıcılara ek bir maliyetle sunmak anlamına geldiği gerçeğini unutmamalıyız - yalnızca bant genişliği açısından değil, aynı zamanda gerçek ekonomik maliyetle de - bazı kullanıcılar biraz daha iyi bir deneyim yaşayabilir. En azından kendi adıma konuşursak, bir web sitesinin altbilgisine "ilk dünyada en iyi görüntülenenler" yerine "Internet Explorer 6'da en iyi görüntülenen" ifadesini koydum. İkincisi, öncekinden daha saldırgan bulduğum şeylerin çok kısa bir listesinde.
Web'e [...] internete bağlanabilen her türlü donanımdan erişilebilir olmalıdır: sabit veya mobil, küçük ekran veya büyük Tim Berners-Lee, Yaşasın Web: Devam Eden Açık Web Standartları ve Tarafsızlık Çağrısı
Filament Group'ta BostonGlobe.com projesi üzerinde çalışırken, görüntülere en büyük boyutta her şeye uyan yaklaşımın tamamen savunulamaz olacağını hemen anladık. Buna yanıt olarak, Scott Jehl bir img etiketine kesme noktaları eklemek için bir yöntem geliştirdi.
Bunun anahtarı, JavaScript aracılığıyla ekranın genişliğini elde etmek ve bu bilgiyi doğru görüntüyü almak için zamanında sunucuya iletmekti - aksi takdirde, daha büyük ekranlarda görüntü başına iki istek yapıyoruz.
Bulduğumuz en etkili çözüm, müşterinin ekranı hakkındaki bilgileri bir çereze yerleştirmekti. En azını söylemek çekici değil, ancak işlevsel: bir belgenin başına bir çerez yerleştirerek, sayfanın gövdesindeki resim isteklerinin yanı sıra müşterinin ekran boyutunu ziyaret ediyor olsalar bile sunucuya açık hale getirilebilir. site ilk kez. Daha sonra orijinal, mobil boyutlu görüntü için isteği yakalayabilir ve onu 1x1 boşluklu bir gif'e yönlendirebiliriz. Kuşkusuz, boşluk bırakıcı gif'ler, çerez tabanlı işlevsellik kadar "1999'daki gibi parti" dir, ancak bu orijinal isteğin etkisini en aza indirmek için mevcut en etkili yöntemdi. Daha sonra, orijinal kaynağı koşullu olarak bir veri özniteliğinde belirtilen kaynakla değiştirmek için JavaScript kullanabiliriz. Bu son adım, kendi başına komplikasyonsuz olmasa da, kıyaslandığında ağrısızdı.
Devam eden "duyarlı görüntüler" destanını takip ediyorsanız, birçok benzer çözüm gibi bu yaklaşımın da o zamandan beri başarısız olduğunu biliyorsunuzdur. Çeşitli tarayıcılar, bir belgenin gövdesinin ayrıştırılmasından önce UA'ların varlıkları getirmesine izin vererek, özellikle agresif bir DNS önceden getirme özelliği uyguladı. Daha hızlı yüklenen sayfalar için fazla üzülmek zordur, ancak bu, ilk isteği ertelemek için istemcinin ekran boyutunu zamanında sunucuya bildiremediğimiz anlamına gelir. Doğrusu, kararlaştırdığımız çerez yöntemi, o sırada büyük tarayıcıların spesifik olmayan davranışına dayanıyordu ve varsayılan davranışa dayalı çözümler nadiren geleceğe en uygun çözüm olduğunu kanıtlıyordu.
Çizim tahtasına tam bir geri dönüşle karşı karşıya kaldık, hedeflerimizi birkaç temel konsepte indirgeyerek başladık:
- Tüm kullanıcılar - her koşulda - temsili bir resim almalıdır.
- Daha büyük ekranlarda gereksiz talebi ortadan kaldırın veya en azından bu isteği elimizden geldiğince azaltın.
- Sanat yönü açısından, bir görüntüyü basitçe ölçeklemek her zaman en iyi yaklaşım olmayabilir. Sunucudaki en büyük görüntüyü yeniden boyutlandırmak yerine alternatif görüntü kaynaklarını belirleyebilmek, daha küçük görüntülerin görüntünün konusuna uyacak şekilde daha uygun şekilde kırpılmasına ve yakınlaştırılmasına olanak tanır.
Yeniden iki katına çıkan çabalarımız sırasında, çabalarını halka açık bir şekilde belgeleyen geliştirici topluluğunun benzer şekilde şaşkına dönen üyelerine ulaştık. Bunu bir beyin fırtınası telaşı izledi ve gecenin geç saatlerinde Git'in kamu tüketimi için uygun olmayan taahhütleri - iğrenç masallar noscript>, dinamik olarak enjekte baz> etiketler ve document.write. Modern geliştiricinin kamp ateşi korku hikayelerine eşdeğerini dokuduk ve bir çözüm arayışında ön uç kodlamanın en karanlık derinliklerini kurguladık. Hoş değildi ve daha da önemlisi: denediğimiz hiçbir teknik işe yaramadı.
Giderek daha fazla hayal kırıklığına uğradıkça, dışarıdan bir bakış açısı elde etmek için tarayıcıların geliştirici ilişkileri ekiplerinin üyelerine girmemiz gerektiği ortaya çıktı. Opera'dan Mike Taylor ve Chrome'dan Paul Irish, devam eden görüşmelerimize katıldı ve sayısız başarısız "duyarlı görüntü" yaklaşımımıza ışık tutmasına rağmen, yeni kazandığımız netliğimiz bizi gerçek bir çözüme yaklaştırmadı.
Yeni öğe
Geliştiriciler sohbete katıldıkça - ve birkaç tarayıcı temsilcisinin sürekli yardımı ile - karşılaştığımız sorunların ancak başlangıç noktamız olarak yeni bir unsurla iyi bir şekilde çözülebileceği giderek daha açık hale geldi.
Fikir, video etiketinin biçimlendirme modelini ilham kaynağı olarak kullanmaktır, çünkü bu, kaynak öğelerinde öznitelikler içinde medya sorgularının kullanımına izin vermek ve işaretlemeyi tanımayan herhangi bir tarayıcıda etiketin içinde güvenilir bir şekilde görüntülemektir. Video ve ses etiketlerinde olduğu gibi, bu çözümün, son kullanıcının bağlamına göre uyarlanmış içeriği güvenilir bir şekilde sunmak için herhangi bir özel komut dosyası, HTTP / SPDY üstbilgisi veya sunucu tarafı teknolojileri gerektirmemesi gerekir. Medya özniteliklerini kullanarak, yalnızca daha küçük ekranlara sahip kullanıcılar uğruna savurgan görüntü taleplerini azaltmakla kalmayabiliriz, aynı zamanda görüntülerimizin çözünürlüklerini yüksek çözünürlüklü ekranlara sahip kullanıcılar veya baskı için uyarlayabiliriz.
Şu anki enkarnasyonuna ulaşmadan önce resmi olarak önerilen işaretleme modelinde sayısız yinelemeden geçtik:
- picture alt = "Alt etiketi, tüm kaynaklar tarafından temsil edilen resmi doğru bir şekilde tanımlamalıdır, ancak kırpma ve yakınlaştırma farklı olabilir.">
- kaynak src = "mobile.webp" />! - Varsayılan olarak eşleşir. ->
- kaynak src = "high-res.webp" media = "min-width: 800px" />! - Herhangi bir varlık getirilmeden önce 800px üzerindeki önceki kaynağı geçersiz kılarak tek bir istekle sonuçlanır. ->
- img src = "mobile.webp" />
- ! - Resim> etiketinin desteklenmemesi durumunda yedek içerik. ->
- / resim>
Paul, W3C’nin nispeten yeni Topluluk Grupları çabasıyla tartışmalarımızı daha da açmamız için bizi cesaretlendirdi. Halkın tepkisi inanılmazdı - Duyarlı Görüntüler Topluluk Grubunu başlattığımızda üretilen trafik, Topluluk Gruplarının sunucularını devre dışı bıraktığı ölçüde. Her zaman yeni sesleri memnuniyetle karşılıyoruz ve bu forum, bant genişliği tespitinden cihazı tanımlayan başlıklara kadar "duyarlı görüntü" sohbetinin diğer yönleri hakkında çok sayıda büyüleyici gönderiye yol açmıştır. Hakkında yayınlamadan önce resim> öğesinin özellikle "Sık Sorulan Sorular ve Endişeler" sayfasını okuduğunuzdan emin olun. Ayrıca grup içinde aylarca süren konuşmalar ve dış sitelerde ve posta listelerinde geçen tartışmalara bağlantı veren çok sayıda gönderi var ve bu mücadeleye atılmadan önce vakit geçirmeye değer. "Bunun yerine JavaScript / CSS kullanmayı düşündünüz mü?" Önerileri, ilk günden beri sürece dahil olan bizler için sürekli bir şaka haline geldi. Söz veriyorum: sahibiz.
Ne yazık ki, kamuoyuna dönük tüm tartışmalara rağmen resim> unsuru, WHATWG tarafından çok fazla ilgi duymadık. Elbette, standartlara derinden dahil olan çoğu insanın çok sayıda sorun ve öneri birikimi altında işgücünü işlediğini anlıyoruz. Bir grup hüsrana uğramış geliştiriciden gelen her yeni öğe talebine anında yanıt bekleyemeyiz - bu istek kaç tane çatıdan duyurulursa duyurulsun. Bununla birlikte, bu sessizlikten vazgeçmemek zor - özellikle de Retina ekranlı iPad'lerin ortaya çıkmasının ve duyarlı web tasarımının hızla benimsenmesinin ardından ekrana uygun görüntülerin sunulmasına ilişkin artan endişeler göz önüne alındığında.
WHATWG'nin nispeten sessiz olmasına rağmen, çabalarımızda heyecan verici bir noktaya ulaştık - önerilen öğemizin örnek bir uygulama için hazır olduğunu hissettiği noktaya.
Resim deseni
Bu süreç boyunca Opera ve Chrome geliştirici ilişkileri ekiplerinin üyeleriyle yakın çalışmanın bir sonucu olarak, resim> işaretleme kalıbı, benim yarı şaka yollu bir şekilde "sözde spek" olarak adlandırdığım şekilde her iki takıma da sunulmuştur. Bu, kelimesi kelimesine kodlanması amaçlanan bir şartname değil, Topluluk Grubundaki düzyazı sayfalarını sayfalarına geçmeden anahtar uygulama ayrıntılarını bulabileceğiniz tek bir yerdir. Bunu şimdilik herkese açık bir GitHub deposunda yayınladım, ancak tartışmayı Topluluk Grubunda merkezileştirmeyi tercih ederim. Aslında, yukarıdaki bağlantıda ana hatlarıyla belirtilen ayrıntılara ve gereksinimlere dayanarak, Scott Jehl zaten bir polyfill yazmıştır. resim>Başka türlü desteklemeyecek tarayıcılar için işlevselliği. Bu çoklu dolgu bugün işe yarayacak olsa da, yine de tamamen teoriktir ve asla bir üretim sahasında kullanılmamalıdır.
Elbette resim deseni mutlak bir ideal olmaktan uzaktır. Bant genişliğini tespit etmenin bir yolunu bulmak, varlıkları optimize edilmiş bir şekilde teslim etmede kesinlikle kritik bir adımdır - bu departmanda az miktarda çalışma yapılmamaktadır. Bize sunulan müşteri tarafındaki yetenekleri tespit etmek için yeni tekniklerden yararlanmanın bir yolunu bulmamız kritik önem taşıyor ve resim öğesi bize sağlam bir temel oluşturacak. Bu unsur bir standart haline gelirse, bize tek bir konuyu temsil eden farklı varlıkları ele almanın bir yolunu, görüntü kaynaklarını çok daha az savurgan bir şekilde sunmak için temel bir yöntem ve eski tarayıcılar için sorumlu bir geri dönüş modeli sağlayacaktır. Video etiketinin kaynak modeline uygun olarak, gelecekteki varlık dağıtımını uyarlama yöntemleri çok çeşitli varlıklar için geçerli olabilir. İmg etiketi, gerekli olabilecek tüm güçlendirme nedeniyle bu amaçlara uygun değildir. Dahası, eskiden beri var olan bir etikette yapılan değişikliklerin eski tarayıcılarda sorunlara yol açmayacağını asla kesin olarak söyleyemezdik.
Resim öğesi img yerine geçmez. Basit bir img öğesinin iş için en iyi araç olacağı zamanlar olurken, resim öğesi daha büyük "kahraman" görüntüler ve yüksek çözünürlüklü fotoğraflar için ayrılacaktır. Bu tür bir esnekliğe sahip olmamız önemlidir ve esnekliğin img etiketinin her zaman anladığı bir şey olduğunu düşünmeyi seviyorum. Elbette kişisel bir şey değil, img etiketi. Ve ne olursa olsun, her zaman kedi giflerimiz olacak.
Kelimeler: Mat Marki
Mat "Wilto" Marquis, Boston'daki Filament Group'ta çalışan bir tasarımcı-eğik çizgi-geliştiricidir. Mat, jQuery Mobile ekibinin bir üyesi, A List Apart'ın teknik editörü ve açık kaynak topluluğunun aktif bir üyesidir. Biz konuşurken muhtemelen Twitter'da bir şeyler hakkında çılgına dönüyor.
