- Safari ve Firefox, TikTok, Netflix, Instagram gibi belirli alan adlarında rendering ve API davranışını değiştiren kodlar dağıtıyor
- Firefox’un about:compat sayfası siteye özel müdahaleleri ve aç/kapa anahtarlarını gösteriyor; özel CSS/JavaScript enjeksiyonu ve kullanıcı aracısı gizlemesi yapıyor
- Safari’nin WebKit motoru bunu quirks olarak yönetiyor; PiP video, görsel hizalama, popover ve streaming erişimi sorunlarını alan adına göre aşıyor
- Chrome’un neredeyse hiç ayrı istisna dosyasına ihtiyacı yok; çünkü web zaten Chrome merkezli inşa ediliyor ve farkları diğer tarayıcılar telafi ediyor
- Bu istisnalar loglarda veya konsolda pek görünmediği için, geliştiricilerin Firefox ve Safari’de düzenli test yapması ve quirks dosyalarında yer alıp almadığını kontrol etmesi gerekiyor
Tarayıcı içindeki alan adına özel istisna işleme
- Safari ve Firefox, kullanıcının ziyaret ettiği alan adına göre rendering’i veya API davranışını değiştiren kodlar dağıtıyor
- TikTok, Netflix, Instagram ve SeatGuru gibi siteler bu tür siteye özel işlemenin hedefi oluyor
- İlgili kaynaklar WebKit’in
Quirks.cpp dosyasında ve Firefox’un WebCompat interventions bölümünde herkese açık biçimde görülebiliyor
- Bu kod, “belirli bir alan adındaysa farklı render et” veya “belirli bir alan adındaysa API çağrısını farklı işle” mantığıyla tarayıcı rendering motoruna yerleştirilmiş durumda
- Chrome’un aynı türden istisna dosyalarına fiilen ihtiyacı yok; bu da web’in zaten Chrome merkezli inşa edilmesinden kaynaklanan asimetriyi ortaya koyuyor
Firefox’un about:compat sayfası
- Firefox adres çubuğuna
about:compat yazıldığında siteye özel müdahale listesi ve aç/kapa anahtarları görülebiliyor
- Her madde belirli bir web sitesi için hazırlanmış özel bir düzeltme; kapatıldığında sitenin bozulduğu görülebiliyor
- Firefox’un WebCompat sistemi, belirli alan adlarına özel CSS ve JavaScript enjekte ediyor
- Tarayıcıyı yanlış algılayan sitelere kullanıcı aracısı dizgesi değiştirilerek gönderiliyor
- Bu müdahaleler, web bozuk görünmesin diye hataları örtüyor; Mozilla Bugzilla üzerinde hata raporları ve siteyle iletişime geçme girişimleri de takip ediliyor
Safari’nin quirks yapısı
- Safari’nin WebKit motoru bu işlemlere quirks adını veriyor ve
Quirks.cpp dosyası GitHub’da açık olarak yer alıyor
- WebKit kodunda, Facebook, X ve Reddit’in ekran dışına kaydırılan
<video> öğelerini PiP modunda olup olmadığına bakmadan duraklattığını belirten bir yorum bulunuyor
- Safari,
facebook.com, x.com, reddit.com alan adlarını algılayarak Picture-in-Picture video işleyişini değiştiriyor
- Sitenin video kodu bozuk olsa bile ilgili şirketlerin düzeltmesini beklemiyor; tarayıcı tüm kullanıcılara doğrudan bir geçici çözüm dağıtıyor
- SeatGuru ile ilgili yorumda
FIXME: Remove this quirk if seatguru decides to adjust their site. ifadesi yer alıyor; bu da site düzeltilirse istisnanın kaldırılabileceğini gösteriyor
- Commit geçmişinde son birkaç ay içinde çeşitli siteye özel düzeltmeler görülüyor
- Zillow’un floorplan görsellerinin ortalanmaması sorunu
- TikTok’ta “please upgrade your browser” mesajının gösterilmesi sorunu
- Instagram Reels’in oynatma sırasında düzensiz biçimde yeniden boyutlanması sorunu
- Netflix’te “Episodes and Info” düğmesinin popover’ı yanlış kapatması sorunu
- Twitch’in sekme değişiminde PiP videoyu duraklatması sorunu
- Amazon Prime Video’nun Safari kullanıcılarının izleme yapmasına izin vermemesi sorunu
Chrome merkezli web ve asimetri
- WebKit’in quirks yapısı ve Firefox’un WebCompat sistemi, sadece bozuk siteleri düzeltmekle kalmıyor; Chrome’un “çalışıyor” tanımını belirlediği durumu da telafi ediyor
- Genel olarak Chrome bir özelliği dağıttığında, pazar hakimiyeti nedeniyle geliştiriciler o özelliği kullanıyor; diğer tarayıcılar da ya o özelliği uyguluyor ya da farkı siteye özel istisnalarla örtüyor
- Safari ve Firefox yetiştiğinde ise bu istisnalar zaten milyonlarca kullanıcıya dağıtılmış oluyor
- WebKit’te, Amazon video sayfalarında ve çeşitli streaming servislerinde Safari’yi Chrome gibi gösteren kullanıcı aracısı override’ları bulunuyor
- Bu siteler Chrome olup olmadığını algılayıp diğer tarayıcılara daha düşük kaliteli bir deneyim sunduğu için, WebKit Safari kullanıcılarını korumak adına tarayıcı kimliğini gizliyor
- Şu anda
Quirks.cpp içinde aşağıdaki gibi sahte bir Chrome kullanıcı aracısı dizgesi yer alıyor
auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;
- Firefox da benzer şekilde çalışıyor;
about:compat içindeki birçok müdahale, siteye “ben Chrome’um” diyen kullanıcı aracısı gizlemesinden oluşuyor
- Mozilla wiki, bazı sitelerin tarayıcı algılama sonucuna göre “erişimi tamamen engellediğini, farklı bir tasarım gösterdiğini veya farklı özellikler sunduğunu” belirtiyor
- Bu yapı bir geri besleme döngüsü oluşturuyor
- Geliştiriciler, Chrome’un pazar payı yüksek olduğu için Chrome’u referans alıyor
- Siteler en iyi Chrome’da çalışıyor
- Diğer tarayıcılarda hata gören kullanıcılar siteyi değil tarayıcıyı suçluyor
- Kullanıcılar Chrome’a geçiyor ve Chrome’un hakimiyeti daha da güçleniyor
- Chrome’un neredeyse hiç ayrı quirks dosyasına ihtiyaç duymamasının nedeni daha iyi tasarlanmış olması değil; web’in zaten Chrome’a göre şekillenmiş olması
- Chromium tabanlı tarayıcı kullanıcılarının oranı %80’i aşmışken, geliştiriciler öncelikle Chrome’u hedefliyor
- Site Chrome’da çalışıyorsa yayına alınıyor; Safari veya Firefox’ta bozuluyorsa sorunun önceliği düşüyor
- Chrome istisna eklemekten çok gündemi belirliyor
- Chrome bir davranışı değiştirdiğinde siteler buna göre güncelleniyor; diğer tarayıcılar da ya peşinden geliyor ya da bozuluyor
Standartlarla gerçek web arasındaki boşluk
- Tarayıcı mühendisleri, güncel standartların iyi tanımlandığını ve HTML5’in “living specification” yaklaşımının IE/Netscape dönemindeki karmaşayı azalttığını düşünebilir
- Sorun, geliştiricilerin standartta yer almayan uygulama ayrıntılarına bağımlı hale gelmesi; bu ayrıntılar başka tarayıcılarda farklıysa, standart dışı olan tarayıcı suçlanıyor
- Chrome’un uygulaması herkesin hedeflediği referans haline geldiğinde, Chrome’un standart dışı ince davranışları fiili standarda dönüşüyor
- 2000’lerde Internet Explorer döneminde de geliştiriciler siteleri IE’ye göre yaptığı için diğer tarayıcılarda siteler bozuluyordu ve standart uyumundan çok “IE’de çalışıyor olması” önemseniyordu
- Geçmişte web standartlara daha iyi uyarsa tarayıcı quirks’lerinin ortadan kalkacağı umuluyordu; pratikte ise quirks kaybolmadı, sadece Chrome dışındaki tarayıcılara taşındı
- Standartlar tarayıcıya özel kodu ortadan kaldırmak için vardı; ancak IE döneminden çıkıldıktan sonra aynı boşluk bu kez başka tarayıcılar etrafında yeniden oluştu
- Artık tarayıcıya özel kod, baskın tarayıcının içinde değil; baskın tarayıcıya göre şekillenmiş web’i telafi etmeye çalışan baskın olmayan tarayıcıların içinde yer alıyor
İstisna işleme sanılandan daha derin
- Bu işlemler sadece görsel ayarlamalarla sınırlı değil; alan adına göre tarayıcının temel davranışını değiştiriyor
- Sadece WebKit listesinin kendisi bile binlerce satır uzunluğunda; scroll davranışı, touch event işleme, viewport hesaplama ve görsel MIME türü işleme gibi konuları kapsıyor
- Amazon ürün görseli yakınlaştırma işlevi için yazılmış yorumda şu ifade yer alıyor
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- Safari, Amazon’a girilip girilmediğini kontrol ettikten sonra ürün yakınlaştırma özelliği için touch event’leri mouse event’lere dönüştürme biçimini değiştiriyor
- Bunun nedeni Amazon sitesinin Safari’nin varsayılan davranışından farklı, belirli bir event davranışını varsayması; Safari de bu davranışı yalnızca Amazon için sağlıyor
- storage access, scrollbar rendering, otomatik düzeltme davranışı ve zoom işleme için de alan adına özel quirks bulunuyor
- Her istisna bir alan adı kontrolünün arkasında yer alıyor ve tarayıcı çalıştırılabilir dosyasının içine derleniyor
Beklemek yerine tarayıcının doğrudan düzeltmesinin nedeni
- Tarayıcı üreticileri bazen sorunlu siteyle iletişime geçip düzeltme talep ediyor; kaynak kodunda outreach çabalarına bağlantı veren alanlar da bulunuyor
- Ancak popüler bir site Chrome’da çalışırken kendi tarayıcılarında bozuluyorsa, kullanıcılar siteyi değil tarayıcıyı suçluyor
- Üçüncü tarafa hata bildirimi göndermek ve haftalar ya da aylar beklemek yerine, ertesi gün 5 satırlık bir geçici çözüm dağıtmak tarayıcı açısından daha pratik oluyor
- Kiminle iletişime geçileceği de net olmayabiliyor
- Bozuk kodu yazan geliştirici şirketten ayrılmış olabilir
- O endpoint’ten sorumlu ekip sorunun kendilerinde olduğunu kabul etmiyor olabilir
- Site yalnızca güvenlik yamaları alan bir bakım modunda olabilir
- Tarayıcı açısından, kullanıcı sorununu hemen ve görünmez biçimde azaltacak düzeltmeyi yapmak daha basit bir tercih
- Bir WebKit mühendisi, FlightAware quirk’ünün kaldırılma sürecini anlatan bir yazı da yayımladı
- FlightAware, CSS transform matrix dizgelerini karşılaştırıyordu; CSS standardı değerlerin serialize edilme biçimini değiştirince, tarayıcı standarda uyduğu anda site bozuldu
- Mühendisler
flightaware.com kontrolü yapan alan adına özel bir kod ekledi; daha sonra iletişim başarılı oldu ve FlightAware kodunu düzelttiği için quirk kaldırıldı
- O birkaç ay boyunca Safari kullanıcıları, tarayıcı içindeki
if ifadesi sayesinde normal bir deneyim yaşayabildi
Geliştiricilerin kontrol etmesi gerekenler
- Bir web sitesi, sahibinin farkında olmadan özel rendering işleme alıyor olabilir
- Bu tür quirks hata loglarında görünmez ve konsolda da “tarayıcı şu anda bir hatayı geçici çözümle aşıyor” şeklinde bir uyarı göstermez
- Geçici çözüm mekanizmaları kasıtlı olarak görünmez çalışır
- Özellikle ağırlıklı olarak Chrome üzerinde test edilen siteler risk altındadır
- Bir sitenin kusursuz çalışmasının nedeni iyi kod olması değil; Chrome’un davranışının geliştiricinin varsayımlarıyla örtüşmesi olabilir
- Diğer tarayıcılar ise siteyi kullanıcıya bozuk halde göstermekle quirks dosyasına eklemek arasında seçim yapmak zorunda kalıyor
- Siteyi Firefox ve Safari’de ara sıra değil, düzenli olarak açıp kontrol etmek gerekir
- quirks dosyaları, geliştiriciler bunu düzenli yapmadığı için var
- Kendi alan adınız bir quirks dosyasında yer alıyorsa, tarayıcının hangi kısmı geçici çözümle telafi ettiğini incelemek gerekir
- Web, geliştirici müdahalesi olmadan çalışmaya devam etmiş olabilir; ancak kullanılmayan tarayıcıların mühendisleri, geliştiricinin fark etmediği sorunları onun yerine çözmüş olabilir
1 yorum
Lobste.rs görüşleri
LLM zırvasının arkasında ilginç bir hikâye gizli
Yazım tarzını beğenmeyebilirsiniz ve bu kısmı özellikle tartışmak istemem, ama bir metnin kötü olması onun mutlaka yapay zeka tarafından yazıldığı anlamına gelmez. Yapay zekadan önce de berbat cümleler vardı
Üzücü bir durum ve keşke Google'ın web üzerinde bu kadar belirleyici olmadığı bir dünyada yaşasak. “Web” hayali çok daha iddialıydı ve kişisel olarak daha ilham vericiydi; bugünkü hâline gelmiş olması üzücü
Alıntı bloklarını okumak zor. Muhtemelen bir dark mode sorunu olabilir
Geçici çözümün ayrıntılarını paylaşmış olması faydalıydı
“Bu siteler Chrome olup olmadığını tespit edip diğer tarayıcılara daha düşük kaliteli bir deneyim sunuyor. Bu yüzden WebKit, Safari kullanıcılarını süründürmek yerine hangi tarayıcı olduğu konusunda yalan söylüyor” kısmı, bu sektörün genelinde tekrar tekrar yaşanan bir şey gibi görünüyor
Bilgisayar üreticileri de azımsanmayacak sıklıkta desteklemedikleri işletim sistemlerinden bilgiyi gizleyen ACPI firmware yayımlıyor; sonunda o işletim sistemleri de firmware'i kandırmak için kendini Windows gibi göstermek zorunda kalıyor
Bu yazının AI üslubu gibi okunmasından hoşlanmadım
Burada bahsedilenlerin dışında iki geri besleme döngüsü daha var. Biri, Chrome baskın olduğu için geliştiricilerin Chrome'a göre geliştirme yapması; bunun sonucunda her şeyin en iyi Chrome'da çalışması; başka tarayıcılarda sorun çıkınca da kullanıcıların suçu siteye değil tarayıcıya atıp Chrome'a geçmesi
Diğeri ise sitenin Firefox'ta bozuk olmasına rağmen site sahibinin istatistiklerde Firefox kullanıcılarını görmediğini söylemesi. Kullanıcı ajanını değiştirme gibi özel işlemler olsa bile bu yaşanabiliyor
Yanlış hatırlamıyorsam klasik Opera(Presto) bu tür uyumluluk katmanlarını ilk uygulamaya başlayanlardandı
Uygulamanın fiilen spesifikasyona dönüşmesi, bu alanda yaygın bir sorun. Önceki işimde, birden fazla uygulama ortaya çıkar umuduyla ve iş akışları taşınabilir olsun diye uygunluk testleri olan bir iş akışı dili kullanmıştım
Asıl sorun, tam taşınabilirlik oluşturmak için ekonomik teşvikin zayıf olması. İnsan kendi uygulamasına ek özellikler koyup kullanıcıların o üründe kalmasını istiyor
Bir de yazılımı komite usulü geliştirecek vakit olmadığından, yeni özellikleri önden uygulamaya koymak istiyorsunuz
Uygulamanın spesifikasyon hâline gelmesi, insan toplumunda yaşıyor olmamızın bir sonucu
Yeni bir şey değil. Az kullanılan tarayıcıların belirli siteler için hep hack'leri vardı; eskiden hedef IE idi. Alternatif, sitenin bozuk kalmasıydı
On yıllar önce web geliştiricileri yalnızca IE'de çalışan siteler yapıp “bu siteyi kullanmak için IE kullanın” diyordu; şimdi aynı şey Chrome ile tekrar yaşanıyor. Chrome'un haklı ya da haksız olması önemli değil. Site sadece Chrome'da çalışıyorsa ve başka bir tarayıcı o sitede Chrome davranışını garanti etmiyorsa, insanlar “bu tarayıcı bozuk” deyip Chrome'a geçiyor
Gerçekten merak ediyorum: İnsanlar Gecko ve WebKit'in ilkeleri uğruna bu siteleri bozuk bırakması gerektiğini mi düşünüyor, yoksa herkesin sadece Chrome kullanıp diğer tarayıcıları bırakması gerektiğini mi? Belirli siteler için yapılan hack'lerin alternatifi sadece bunlar
Firefox ve Safari'nin user-agent olarak Chrome gibi davranması bana komik geliyor
Ama Chrome'un user-agent dizgesinde de kendini Mozilla tarayıcısı ve Apple tarayıcısı gibi göstermeye çalıştığı zamanlardan kalma fosil izler duruyor
Bu tek satır kodda jeolojik katmanlar birikmiş durumda: