HTML spesifikasyonundan XSLT referanslarını kaldırma önerisi

 (github.com/whatwg)
2 puan yazan GN⁺ 2025-08-20 | 1 yorum | WhatsApp'ta paylaş
  • HTML standart belgesinden XSLT ile ilgili referansların kaldırılmasını amaçlayan bir Pull Request önerildi
  • Öneriyi sunan kişi, Chrome, Firefox ve Safari gibi büyük tarayıcılarda ilgili uygulama hatalarının raporlandığını; test ve dokümantasyon konularının da sürdüğünü açıkladı
  • Karşı çıkanlar, mevcut web siteleriyle uyumluluk sorunlarına ve <?xml-stylesheet?> kaldırıldığında XML belgelerinde oluşacak okunabilirlik sorununa dikkat çekti
  • Bazı geliştiriciler, XSLT'nin hâlâ resmî belgeler, RSS ve gömülü ortamlar gibi alanlarda kullanıldığını vurguladı
  • Kararın büyük tarayıcı üreticileri etrafında şekillenmesinin, web'in açıklığını ve tarihsel çeşitliliğini daraltabileceği yönünde endişeler dile getirildi

Pull Request özeti

  • PR başlığı: Remove mentions of XSLT from the html spec
  • Öneren: mfreed7
  • Hedef: whatwg/html:main
  • İlgili konu: #11523
  • Chromium, Gecko ve WebKit tarafında ilgili uygulama hata raporları mevcut
  • MDN belgesi ve HTML AAM gibi ilgili kaynakların güncellenmesi planlanıyor

Başlıca karşı görüşler

gucci-on-fleek (2025-08-15)

  • Kullanım istatistikleri ve web sitesi ölçeğinin dikkate alınması gerektiğini savundu
    • Büyük siteler güncellenebilir; ancak küçük/kişisel siteler onlarca yıldır korunmadığı için kalıcı uyumluluk kırılması riski var
    Reklam
  • XSLTProcessor() kaldırılırsa yalnızca JS işlevi sınırlanmış olur; ancak <?xml-stylesheet?> kaldırılırsa XML belgeleri hiç görüntülenemeyebilir
  • Eski HTML özellikleri (<font>, <align>, <xmp>) hâlâ çalışırken, bu değişikliğin doğrudan belgenin kendisini bozacak emsalsiz bir değişim olduğu belirtildi
  • Eski arşivler ve üniversite siteleri gibi önemli kaynaklara erişimin engellenebileceği riski vurgulandı

nomis (2025-08-18)

Reklam

jonsterling (2025-08-18)

  • Tarayıcı üreticilerinin web platformunu fiilen tek taraflı tanımlamasını eleştirdi
  • XSLT'nin hâlâ çeşitli ve yaratıcı web kullanımlarına katkı sunduğunu, kaldırılmasının Açık Web'i zayıflatacağını savundu
  • "Web hepimizin" ilkesini vurgulayarak, tarihe ve çeşitliliğe saygı gösterilmesi gerektiğini belirtti

Destek ve takip adımları

  • domenic (2025-08-19): Olumlu tepki verdi ve DOM spesifikasyonundaki XSLT referanslarının da güncellenmesi gerektiğini söyledi
  • mfreed7 (2025-08-19): DOM spesifikasyonu için de ayrı bir PR açacağını yanıtladı

Özet

  • XSLT'nin kaldırılması, tarayıcıları sadeleştirme ve güncelleştirme çabalarının bir parçası olarak önerildi
  • Ancak karşı taraf, mevcut belge uyumluluğunun, resmî/akademik veri erişiminin ve Açık Web çeşitliliğinin zarar görebileceği görüşünde
  • Tartışma, basit bir teknik tercih olmanın ötesine geçerek web standartlarını belirleme yetkisinin kimde olduğu yönünde felsefi bir tartışmaya da uzanıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-20
Hacker News görüşleri

  • Dikkat çeken birkaç nokta var

    • Bu karar yalnızca Chrome'un tek başına attığı bir adım değil; issue takibi ve ilgili standart toplantısı kayıtlarında, tüm büyük tarayıcıların temsilcilerinin destek verdiği görülebiliyor

    • Son gündem maddesi de bir Mozilla mühendisi tarafından önerildi

    • Bir PR gönderilmiş olması, bunun hemen merge edileceği anlamına gelmiyor; hâlâ işaretlenmemiş epey görev var

    • Ancak birden fazla tarayıcı üreticisi aynı fikirde olduğundan merge edilme olasılığı yüksek

    • XSLT'nin web platformundan kaldırılıp kaldırılmamasını tartışan issue, topluluktan görüş toplamak için değil, HTML spec bakımcıları arasındaki tartışma için açılmış bir issue

    • Bu issue bir Chrome mühendisi tarafından açıldı ama Mozilla mühendisleri bu konuyu toplantılarda defalarca gündeme getirdi ve üreticiler arasında zaten bir uzlaşma vardı

    • Ciddi bir güvenlik açığı tespit edilmişti

    • libxslt'nin ana bakımcısı da bizzat इस्तifa etti

    • Başlıktan Chrome kelimesini çıkardım

    • İlk gönderilen başlık "Chrome intends to remove XSLT from the HTML spec" idi

    • Chrome'un telemetri verilerine göre XSLT'yi gerçekten kullanan web sitesi neredeyse yok

    • Bu önerinin tüm web üzerinde büyük bir etkisi olmayacağı en azından verilerle doğrulanabiliyor

    • Eskiden Mozilla ve Google'da (Chrome ekibi) çalışmış bir geliştiriciyim

    • Chrome/Blink, Safari/Webkit ve Firefox/Gecko'nun hepsinin XSLT'nin kaldırılmasını desteklediğini anlıyorum, ancak iki projede kaynak sıkıntısı var ve bir tanesi de yeni özellikleri agresif biçimde zorlamaya eğilimli

    • Safari ve Firefox geliştiricilerinin böyle bir değişikliği memnuniyetle karşılaması için nedenler de var

    • Önemli olan, 'otorite sahibi insanların bunun iyi bir fikir olduğunu düşünüp düşünmediği' değil, 'bu fikrin web platformuna ve milyarlarca kullanıcıya olumsuz etki yapıp yapmayacağı'dır

    • Milyarlarca kişi içinde yalnızca %0,1'i bile buna bağımlıysa bu yine de ciddi bir ölçektir

    • Kimse kullanmıyorsa polyfill'in var olması için de bir neden yoktur

    • Yeni özellik eklemek istiyorsanız mutlaka eski bir özelliği kaldırmanız gereken sıfır toplamlı bir oyuna dönüştürmek doğru değil

    • Google, yeterli sermaye ve insan gücüne sahip olmasına rağmen XSLT desteğini bilinçli olarak sürdürmemeyi seçiyor

    • Birden fazla üreticinin uzlaştığı için hemen ilerletilen örnekler sık sık oldu

    • confirm/prompt kaldırılması da böyleydi ama sonunda süresiz olarak ertelendi

    • Google'da resmî olarak ilişkili bir özellik kaldırma süreç dokümanı var
      Google feature removal doc

    • "Üretici desteği" gerçek kullanım durumunu yeterince incelemedi

  • Okuduğum iki başlıkta da Google geri bildirim istedi, ama geri bildirimlerin neredeyse tamamı "bunu yapmayın" yönündeydi

    • Buna rağmen Google'ın tavrı "görüşler için teşekkürler, yine de yapacağız!" oldu

    • Eğer mesele güvenlikse, açık kaynağa destek vermek, daha güvenli bir kütüphaneye geçmek ya da JS sandbox içinde yaşatmak gibi birçok alternatif vardı ama bunların çoğu göz ardı edildi

    • XSLT 3.0 gibi daha yeni sürümlerin desteklenmesi talepleri de sürekli geldi ama karşılık bulmadı

    • XSLT açık web'i destekleyen bir teknoloji olmasına rağmen, Google 10 yıldır desteği azaltıp onu kaderine bırakarak pazar payı düşüşünü kaldırma gerekçesi olarak kullanıyor

    • XSLT'nin yeniden ilgi görmeye başladığı bir dönemde, açık bir rakip ortaya çıkmadan önce öldürülmek istendiği hissi var

    • İlgili issue

    • Geri bildirimlerin çoğunun "yapmayın" olduğu iddiasına karşılık, ilgili başlık kötü niyetli yorumlar, hakaretler vb. nedeniyle erken kilitlendi

    • "Bu iyi bir fikir" türü yorumlar normalde pek yazılmadığı için sanki sadece karşı çıkanlar varmış gibi görünebilir

    • Herkes aşırı bir üslupla konuştuğu için tartışma dağıldı; bunu biraz da kendileri hazırladı

    • Eğer "lütfen yapmayın" diyenler gerçekten kullanıcı değilse ya da bunun neden gerekli olduğunu açıklayamıyorsa, geliştirme ekibinin onları görmezden gelmesi makul olabilir

    • Geri bildirim istemek basit bir lehte/aleyhte oylama değildir

    • XSLT 3.0'ı JS/wasm sandbox'a taşıyıp desteklemek mümkün olsaydı güzel olurdu

    • Bir miktar performans kaybı olurdu ama iki tarafın avantajları da alınabilirdi

    • XML'de sürümleme şemaları, namespace'ler gibi özellikler sayesinde entegrasyon görece kolaydır

    • Angular gibi js framework'lerinden farklı olarak güvenilir veri sözleşmeleri kurulabilir

    • XML ailesinin olgunluğu sayesinde çok sayıda profesyonel araç vardır; pratikte XML/XSD ile doğrudan metin düzeyinde uğraşmak bile gerekmez

    • Google, web'de ne olacağını "soru biçiminde" önceden haber veriyor gibi davranıyor

  • Önceki ilgili başlıklara giriş

  • Bir tarayıcının belirli bir template engine'e (XSLT) gömülü destek vermesi gerekip gerekmediğinden emin değilim

    • Jinja gibi bir metin motoru değil ve JS/wasm ile yeniden uygulanması da mümkün

    • Günümüz tarayıcıları fazla ağır ve yeni bir motor geliştirmek zor

    • Keşke sadece "minimal tarayıcılar" için daha basit bir standart olsa; temel etiketler, yerleşim vb.

    • WebAudio, Canvas gibi şeyler de wasm modülleri olarak uygulanabilir (ve bu sayede fingerprinting de önlenebilir)

    • XSLT, belirli bir motor değil, template engine'lere dair bir "spec"tir; birden fazla implementasyonu vardır

    • Mozilla, libxslt yerine transformiix kullanıyor

    • Jinja basit metin işlemedir; XSLT ise node düzeyinde çalıştığı için çok daha güçlüdür

    • JS dönüşümü, XSLT'nin yerel dönüşümünden çok daha yavaştır ve sonucu cache'lemek de zordur

    • XSLT'ye eski teknoloji gibi bakanları anlayabiliyorum ama son 20 yılda performans açısından gizli bir silah gibi çok iyi iş gördü

    • Google sonunda bu sorunu AMP gibi bir alternatifle örtmeye çalışacaktır

    • Tarayıcıların ağır olmasının sebebi Google'dır

    • XSLT bir dil(spec), motor değil

    • JS/wasm implementasyonuna geçmek iç uygulama meselesidir; bu, dilin web platformundan kaldırılmasıyla aynı şey değildir

    • Audio veya canvas, tarayıcının temel I/O yetenekleridir; bunları wasm'a taşımak performans ve uyumluluk açısından ciddi sorunlar doğurur

    • Audio'nun bazı parçaları wasm blob'a taşınabilir ama tamamını taşımak zordur

    • Canvas context ya da WebGL gibi şeylerin özü GPU ile doğrudan entegrasyondur; bunu wasm ile gerçekleştirmek mümkün değildir

    • Sonuçta bunlar zaten fiilen temel primitive API'lerdir ve vazgeçilemeyecek alanlardır

    • Eski XSLT kodunu wasm olarak paketleyip eski siteleri bozmadan uyumluluk sağlama fikri de tartışıldı

    • Hatta içeride gerçekten değerlendirildi ama yapılmamasına karar verildi

    • Web'le pek ilgisi kalmamış ve çok az kişinin kullandığı özelliklerin kaldırılabilir olduğunu düşünüyorum

    • Ama güvenlik açığını gerekçe olarak kullanmaya katılmıyorum

    • Bellek güvenli bir paketin olup olmadığı bile kontrol edilmeden bu gerekçe ikna edici durmuyor

    • Gerçek kullanım oranının %0,001 düzeyinde olduğu da söyleniyor

  • HTML spec'inin temel vaadini bozmak çok ciddi bir konu

    • Tartışmanın bunu derinlemesine ele almaması daha da şaşırtıcı

    • HTML, "bu HTML'dir, güvenebilirsin" vaadiydi; şimdi ise "şimdilik HTML, ama gelecekte de öyle kalacağının garantisi yok" anlamına geliyor

    • XSLT'yi kaldırma mantığıyla başka eski teknolojiler de kesilmeye devam edebilir

    • Sonuçta bu, web'in 'long tail' kısmını koparma önerisidir

    • Ayrıca ileride eklenen çeşitli web teknolojilerinin de zamanla bir long tail'e dönüşüp daha fazla kaldırma hedefine dönüşeceği de düşünülmeli

    • Eski medya ve yazılım desteğinde, bir noktada taşıma, emülasyon ve arşivleme gibi yöntemlere geçme zamanı geleceğini düşünüyorum

    • Değişime hazırlanmak için yeterli zaman ve araç sağlamakla, karmaşıklığın kademeli birikimini önlemek arasında denge kurulmalı

    • Gerçek PR'da kaldırılan kısımlara bakınca, HTML'in XSLT desteğini zorunlu kılan açık bir hüküm görünmüyor

    • Daha çok tarayıcı desteği meselesine verilen büyük tepki dikkat çekiyor

    • PR'ın kendisi şaşırtıcı derecede kısa

    • WHATWG, HTML'i "Living Standard" olarak tanımladığından, pratikte artık bir implementasyon standardından çok tarayıcı üreticilerinin o anda üzerinde çalıştığı durumu paylaşan bir yapı gibi işliyor

    • Bu yüzden HTML5 gibi sürüm adlandırmalarını da kaldırıp sadece "HTML" demeye başladılar

    • Living Standard FAQ

    • HTML standard FAQ

    • İronik olan şu ki HTML/CSS/tarayıcı spec'lerine devasa miktarda özellik iten başlıca şirketlerden biri de tam olarak Google

    • Eğer Google sürekli olarak "tarayıcılar hafif olmalı, tuhaf şeyler JS kütüphanelerine bırakılmalı" çizgisini savunsaydı bu adım daha anlaşılır olabilirdi, ama durum hiç öyle değil

  • FTP desteği kaldırıldıktan sonra XSL'in kaderi zaten belliydi

    • Tarayıcılar saldırı yüzeyini azaltmayı en büyük öncelik haline getirme eğiliminde

    • Sıradaki kaldırma adaylarının SVG SMIL animasyon özellikleri, MathML gibi XML bağlantılı yetenekler olabileceğini düşünüyorum

    • İlgili başlık

    • SMIL, belirli animasyonların başlama/bitiş zamanına göre sıralı animasyon kontrolü sağlayabiliyor ama CSS animasyonları bu konuda hâlâ yetersiz

    • CSS'te hesaplamaya dayalı zamanlama dışında bir yol yok

    • Chromium da bir dönem SMIL'i kaldırmak istemişti ama CSS yeterli olmadığı için bu çok erkendi

    • Bunun etkisiyle SMIL'le ilgili pek çok rehber ve duyuru güncellenmeden kaderine bırakıldı

    • Saldırı yüzeyini azaltmanın gerçekten iyi mi kötü mü olduğunu sormak istiyorum

    • Mühendislerin ve sıradan kullanıcıların öncelikleri farklı olabilir

    • FTP özelliğinin ne zaman kaldırıldığını merak ediyorum

    • Bildiğim kadarıyla adres çubuğunda hâlâ ftp:// yazıp erişilebiliyor

  • Blink ve WebKit'in XSLT implementasyonu çok verimsiz

  • Bu karar üzücü ama daha modern bir XSLT entegrasyonuna emek verilmemiş olması daha da üzücü

    • Kullanımı rahatsız ediciydi ama tarayıcıda biraz daha evrilseydi React gibi framework'lere rakip olacak bir alternatif haline gelebilirdi

    • XML, büyük şirketlerin getirdiği karmaşıklık olmasaydı, standardın kendisi çok güçlü ve etkileyici bir teknolojiydi

    • XSLT ile küçük ve basit xml/verileri doğrudan html'e dönüştürmek gerçekten çok güzeldi

    • Seçili öğeleri farklı gösterecek küçük bir özellik daha eklenebilseydi, statik belgeler dâhil çok farklı kullanım alanları olabilirdi diye düşünüyorum

  • @whatwg, tartışmanın "fazla ısındığını" söyleyerek ilgili issue'yu yalnızca işbirlikçilere açık olacak şekilde kilitlemiş

    • Bana oldukça makul ve sakin görünüyordu ama belirli bir üreticiye ne kadar yakın olduğuna göre "fazla ısındı" eşiği değişiyor olabilir diye düşündürüyor

    • "Fazla ısındı" ifadesi çoğu zaman karşıt görüşlerle uğraşmak istememek anlamında yorumlanıyor

    • Reddit gibi diğer topluluklarda da durum benzer

    • Gerçekte altında kalan tek yorum, Google Chrome ekibinden bir geliştiricinin "iyi iş çıkarmışsınız" mesajı

    • Biraz rahatsız edici görünüyor

    • Issue tracker'a hakaret, komplo teorileri, siyasi mesajlar gibi çok sayıda şikâyet amaçlı gönderi aktığı örneklerden söz ediliyor

    • Böyle olunca üretken tartışma zaten imkânsız hale geliyor ve depo yöneticilerinin tartışmayı hızla kapatması kaçınılmaz oluyor

    • Bu deponun tartışma kilidinin aslında bir Apple çalışanı tarafından uygulandığını duydum

    • Ama insanlar suçu bu issue'yu açan Google çalışanına yüklüyor

    • Google yakın zamanda topluluk görüşü toplama adına açık bir tartışma yürüttü ama sonrasında tüm görüşleri görmezden gelip istediğini dayatıyor gibi görünüyor

    • İlgili issue

  • Eski web öğeleri hakkında genel bir değerlendirmeye ihtiyaç var

    • Benim için eski web sayfalarının da çalışmaya devam etmesi çok değerli

    • HTML/JS'in uyumluluğu koruması sayesinde onlarca yıllık sayfalar bile yalnızca TLS sertifikası eklenince hâlâ düzgün çalışıyor

    • Ama tüm miras teknolojileri sonsuza kadar desteklemek de mümkün değil

    • Flash de sonunda emülatörler (Ruffle) üzerinden nostaljik oyunlar ve siteler deneyimlenir hale geldi

    • Uzun vadede eski render davranışlarına özel tarayıcılar veya emülatörler de bir seçenek olabilir

    • Bunun için zaten bir XSLT polyfill uzantısı çıkmış durumda

    • Chrome bunu resmî olarak dağıtmak veya bakımını üstlenmek istemiyor

    • Durum Ruffle ile oldukça benzer