· kaynak dev.to (home feed)
Chrome 158, tarayıcı tarafında XSLT desteğini kaldırıyor; siteler sunucu tarafına dönüşüme yönlendiriliyor
Chrome 158, 17 Kasım 2026'da XSL stylesheet'lerini uygulamayı bırakıyor ve tarayıcı tarafında XSLT dönemi kapanıyor. Dev.to'daki bir rehber, Chrome'un sunduğu dört seçeneği ve kalıcı çözümün neden sunucu tarafında dönüşüm olduğunu anlatıyor.

Chrome 158, XSL stylesheet'lerini uygulamayı bırakıyor
17 Kasım 2026'da Chrome 158'in yayınlanmasıyla tarayıcı, XML sayfalarda XSL stylesheet'lerini uygulamayı bırakacak. Bağlantılı bir .xsl dosyasıyla XML sunan her site — ürün katalogları, dokümantasyon dökümleri, veri dosyalarının okunabilir kopyaları — ziyaretçilerin artık biçimlendirilmiş sonucu göremediğini fark edecek. Dev.to'da yayınlanan bir göç rehberine göre kesinti tarihi kesin, ancak iki kaçış kapısı var: origin trial'a kaydolmuş siteler ve kurumsal politika ile yönetilen tarayıcılar, 17 Ağustos 2027'de çıkması planlanan Chrome 176'ya kadar XSLT'yi çalıştırabilmeyi sürdürecek.
Chrome'un sunduğu dört yol
Dev.to makalesi, etkilenen site sahipleri için dört seçenek sunan Chrome'un duyurusunu aktarıyor: dönüşümü sunucuda çalıştırıp düz HTML göndermek; XML belgeye xslt-polyfill betiğini ekleyerek stylesheet'in tarayıcıda yeniden uygulanmasını sağlamak; XML yerine JSON sunup JavaScript ile render etmek; ya da XSLT'yi sayfanın içinde bir JavaScript kütüphanesiyle çalıştırmak — duyuruda bunların en büyüğü olarak Saxonica'nın kütüphanesi, tam XSLT 3.0 desteğiyle anılıyor.
Rehbere göre polyfill en küçük değişiklik, ancak her JavaScript yaklaşımı gibi ziyaretçinin tarayıcısında çalışmaya devam ediyor. Sunucu tarafında dönüşüm daha fazla emek gerektiriyor, ama çıktısı hiçbir tarayıcının neyi desteklediğine bağlı kalmayan tek yol.
PHP, Python veya Node.js ile sunucu tarafında
PHP'de XSL eklentisinin XSLTProcessor sınıfı, XML ve XSL belgelerini alıp text/html olarak gönderilecek bir HTML dizisi döndürüyor. Eklentinin --with-xsl ile derlenmiş olması gerekiyor ve yazar, elindeki resmi WordPress Docker imajının PHP 8.3 sürümünde bu eklentinin bulunmadığı uyarısını yapıyor; bu yüzden o örnek doğrulanmış bir çalışmadan değil, PHP kılavuzuna dayanıyor.
Python'ın lxml kütüphanesi, libxslt üzerine kurulu XSLT sınıfını sağlıyor. Yazar bu yolu Python 3.14.3 ve lxml 6.0.2 ile çalıştırıp beklenen HTML tablosunu elde etmiş. Node.js'te yerleşik bir işlemci yok, bu yüzden saxon-js ya da xslt-processor gibi bir paket gerekiyor.
Bilinmeye değer iki XSLT tuzağı
Site haritaları öğelerini varsayılan bir namespace'e yerleştirir ve XSLT 1.0'ın ifade dili olan XPath 1.0, varsayılan namespace'leri tamamen yok sayar. Bir stylesheet bir prefix bildirmeli ve urlset/url yerine s:urlset/s:url seçmeli, yoksa ortaya çıkan tablo boş döner. Rehberin açıkladığı gibi, bir site haritası stylesheet'inin sessizce hiçbir şey üretmemesinin klasik nedeni budur.
İkincisi, libxslt çıktısı DOCTYPE içermez ve MDN'nin belgelediği gibi doctype'ı olmayan bir sayfa standartlar modu yerine quirks modunda render edilir. xsl:output'a doctype-system="about:legacy-compat" eklemek, yazarın testinde lxml'den düzgün bir çıkmasını sağlamış; exclude-result-prefixes özniteliği ise yardımcı namespace'i bitmiş markup'ın dışında tutuyor.
Site haritalarını ya da feed'leri HTML'e dönüştürmeyin
Arama motorları ve feed okuyucuları bu URL'leri çekiyor ve onlara XML gerekiyor. Google'ın site haritası dokümantasyonu XML site haritaları, RSS, mRSS, Atom 1.0 ve metin dosyalarını kabul ediyor — HTML sayfa bunlar arasında yok, dolayısıyla /sitemap.xml'i HTML ile değiştirmek, yalnızca insanları etkileyen bir görüntüleme sorununu çözmek uğruna taramayı bozuyor. Rehberin tavsiyesi, XML'i olduğu yerde bırakmak ve insanların okunabilir bir görünüme ihtiyacı varsa HTML'yi ayrı bir adreste yayınlayıp ona bağlantı vermektir. Feed'leri CSS ile biçimlendirmek Chrome'da hâlâ çalışıyor.
Zamana ihtiyaç duyan siteler origin trial'a kaydolup token'ını Origin-Trial HTTP yanıt başlığı üzerinden ekleyebilir, çünkü XML belgelerde bir meta etiketi taşıyacak HTML head öğesi yoktur.
Neden önemli
Chrome'un belirttiği gerekçe bellek güvenliği: libxslt gibi kütüphaneler karmaşık, yaşlanan ve bellek güvenliği hatalarına açık C/C++ kodlarıdır; bunları tarayıcıdan çıkarmak, render yolundan tüm bir risk sınıfını kaldırıyor. Site sahipleri için 17 Kasım 2026, sonrasında biçimlendirilmiş XML sayfaların çoğu ziyaretçi için sessizce bozulduğu kesin bir son tarihtir. Sunucu tarafında dönüşüm kalıcı yanıttır, ama kendi dikkat yükünü de beraberinde getirir: kendi stylesheet'lerinizi kendi XML'iniz üzerinde çalıştırın, asla bir kullanıcının verdiği stylesheet'i değil, ve libxslt'yi sistem güncellemeleriyle yamalı tutun.
- #chrome
- #xslt
- #xml
- #web-standards
- #server-side