Bunun için JavaScript’e ihtiyacınız yok

• Web özellikleri geliştirirken HTML, CSS, JavaScript sırasıyla daha az güçlü teknolojileri önce değerlendirmek, yükleme hatalarını ve erişilebilirlik sorunlarını azaltmak açısından avantajlıdır
• JavaScript tarayıcı davranışını doğrudan kontrol edebilir, ancak ek kaynaklar ve hata olasılığı nedeniyle klavye ve yardımcı teknoloji kullanıcılarını dışarıda bırakmayı kolaylaştırır
• Eskiden JavaScript gerektiren onay kutusu anahtarları, datalist, input type="color", details/summary, dialog gibi özellikler artık HTML/CSS’in yerleşik özellikleriyle büyük ölçüde mümkün hale geldi
• HTML ve CSS’in bildirimsel özellikleri, tarayıcının yerel davranışı, kullanıcı ortamı ayarlarını ve erişilebilirlik uyarlamalarını üstlenebilmesini sağlayarak daha iyi varsayılanlar sunabilir
• Alışılmış JavaScript uygulamaları çalışmaya devam etse bile güncel HTML/CSS alternatiflerini düzenli olarak kontrol etmek, değişiklik yaparken de erişilebilirlik testlerini birlikte yürütmek gerekir

---

En az yetki kuralı

• En az yetki kuralı, hedefe ulaşabilecek en az güçlü dili seçmeyi söyleyen bir web geliştirme ilkesidir
• Web’de bu genellikle HTML’i CSS’ten, CSS’i de JavaScript’ten önce değerlendirmek şeklinde uygulanır
• JavaScript bu üç teknoloji içinde en çok yönlü olanıdır, ancak yükü de buna paralel olarak daha büyüktür
  • Bozulabilir
  • Yüklenemeyebilir
  • İndirme, ayrıştırma ve çalıştırma için ek kaynaklar gerektirir
  • Klavye kullanıcılarını ve yardımcı teknoloji kullanıcılarını dışarıda bırakmayı kolaylaştırır
• HTML ve CSS, emirsel JavaScript’ten farklı olarak bildirimsel çalışır
  • Geliştirici tarayıcıya ne istediğini bildirir; uygulama yöntemini tarayıcı seçer
  • Tarayıcı daha verimli bir işleme yöntemini seçebilir
• Tarayıcı HTML/CSS özelliklerini işlediğinde performans, yerel davranış, kullanıcı ortamı ayarlarına uyum ve erişilebilirlik açısından avantaj sağlayabilir
  • Ancak erişilebilirlik her zaman otomatik olarak garanti edilmez

Eskiden JavaScript gerektiren özellikler

• Tarayıcı geliştiricileri ve spesifikasyon yazarları, birkaç yıl öncesine kadar JavaScript gerektiren özellikleri CSS ve HTML’e taşımaya devam etti
• Web geriye dönük uyumluluğu koruduğu için, bir kez öğrenilen uygulama biçimleri araç kutusunda kalıp tekrar tekrar kullanılmaya yatkındır
• Bir özellik için JavaScript gerektiğini biliyor olsanız bile bunun hâlâ geçerli olup olmadığını ara sıra kontrol etmek daha iyi web siteleri yapmanıza yardımcı olabilir

Onay kutusuyla yapılan özel anahtar

• Özel anahtarlar div, onclick işleyicisi ve iç durum yerine temel onay kutusu ve CSS ile uygulanabilir
• <label> içine <input type="checkbox"> koyarsanız tarayıcı ikisini birbirine bağlar
  • Etiketin herhangi bir yerine tıklamak onay kutusunu değiştirir
  • Ayrı bir onclick işleyicisi gerekmez
• appearance: none, tarayıcının varsayılan form denetimi çizimini durdurur ve doğrudan stil vermenizi sağlar
  • input öğesinin kendisi anahtar arka planı gibi süslenebilir
  • ::before, açılıp kapanan iç nokta olarak kullanılabilir
• :checked sözde sınıfı, işaretli olma durumuna göre arka plan rengini ve ::before konumunu değiştirebilir
• Klavye kullanıcıları için odak göstergesi gerekir
  • Odağı outline: none ile gizlemek iyi bir yöntem değildir
  • :focus-visible, yalnızca klavye etkileşiminde iyi görünen bir odak halkası gösterebilir
  • outline-offset ile odak dış çizgisini öğenin dışına veya içine ayarlayabilirsiniz
• input:focus { outline-color: transparent; }, normal durumlarda dış çizgiyi saydam yapıp yüksek kontrast modunda kullanıcının seçtiği renkle yeniden görünür hale getirebilir
• Zorunlu renkler modu hakkında daha fazlası için forced colors explained yazısına bakılabilir

datalist ile yerel otomatik tamamlama

• datalist, kullanıcı yazarken seçenek listesini gösteren tarayıcı yerleşik otomatik öneri özelliğidir
• Yapısı basittir
  • datalist öğesine id ve birden çok option eklenir
  • input öğesinin list niteliğiyle ilgili datalist bağlanır
• Kullanıcı yazdığında tarayıcı açılır listeyi gösterir ve seçenekleri girilen içeriğe göre otomatik olarak filtreler
• Bu temel bir giriş alanı olduğu için listede olmayan değerler de doğrudan girilebilir
• Giriş alanını seçtikten sonra ok tuşlarıyla listede gezinebilir veya tarayıcının eklediği açılır liste simgesine tıklayarak tüm seçenekleri görebilirsiniz

input type="color"ın varsayılan renk seçicisi

• Tek satır <input type="color"> ile tarayıcının yerel renk seçicisini kullanabilirsiniz
• Çok sayıda JavaScript ile oluşturulmuş canvas arayüzlerinin ve kaydırıcıların yerini alabilir
• Chromium tarayıcılarındaki yerel renk seçici yalnızca site içinde değil, ekranın herhangi bir yerinden renk seçebilir
• Her kullanıcı tarayıcı renk seçicisini kullanamayabileceği için, normal metin girişi gibi renk seçmenin başka bir yolunu da birlikte sunmak iyi olur

details ve summary ile akordeon

• details ve summary öğeleri, içeriği kapatıp açan akordeon yapısını tarayıcının varsayılan özelliği olarak sunar
• Varsayılan davranış basittir
  • details içindeki içerik, summary hariç gizlenir
  • Kullanıcı summary öğesine tıkladığında kalan içerik gösterilir
• open niteliği başlangıçta açık durumu belirtir
  • Kullanıcı etkileşiminden sonra sabit kalan bir değer değildir; kullanıcı açıp kapattıkça durum değişir
• summary::marker ile varsayılan üçgen işaretçi stillendirilebilir
  • İçerik emoji vb. ile değiştirilebilir
  • Arka plan rengi, arka plan görseli, yazı tipi boyutu gibi değerler ayarlanabilir
  • Birçok CSS özelliği çalışmaz ve tamamen farklı bir konuma yerleştirme gibi stillendirmeler sınırlıdır
• Safari’de ::-webkit-details-marker sözde öğesi gerekir
• İşaretçi içeriğini değiştirmek, yardımcı teknolojilerin akordeonu duyurma biçimini etkileyebileceğinden details/summary inconsistencies yazısına başvurulabilir
• summary tıklanabilir olsa da varsayılan olarak bağlantı gibi imleç göstermediği ve düğme gibi görünmediği için, tıklanabilir olduğunu göstermek üzere hover ve focus durumları eklenmelidir

dialog ile modal

• alert(), prompt(), confirm() kullanıcıya bildirim gösterebilir veya onay alabilir, ancak ana iş parçacığını kilitler ve tasarıma uygun şekilde stillendirilmesi zordur
• Kendi diyalogunuzu oluşturduğunuzda erişilebilirlik işlemleri karmaşıklaşır
  • Odağı diyalog içinde tutmak gerekir
  • Modal olduğunu bildirmek gerekir
  • Kullanıcının yanlışlıkla dışarı çıkmasını engellemek gerekir
  • Çok yüksek z-index değerine sahip widget’larla çakışabilir
• Tarayıcının dialog öğesi yerel diyalog sağlar
• Şu anda diyalogu açmak için JavaScript gerekir
  • JavaScript olmadan açmayı sağlayacak değişiklik üzerinde çalışılıyor, ancak henüz tam olarak spesifikasyona girmiş veya uygulanmış değil
  • Diyalogu showModal() fonksiyonuyla açabilirsiniz
• dialog, top layer içinde açılır
  • top layer, HTML’den ayrı yeni bir katmandır
  • Bu katmandaki öğeler, z-index ve yığınlama bağlamı iç içeliğinden bağımsız olarak her zaman üstte gösterilir
  • Kavram açıklaması için MDN’deki Top layer sayfasına bakılabilir
• dialog varsayılan bir kapatma arayüzü sağlamadığı için bunu kendiniz eklemeniz gerekir
  • form method="dialog" gönderildiğinde tarayıcı diyalogu kapatır
  • İki gönder düğmesine farklı value değerleri koyarsanız onay diyalogu gibi kullanılabilir
  • close olayında dialog.returnValue okunarak kullanıcının bastığı düğmenin değeri kontrol edilebilir
  • Ek form verileri FormData ile okunabilir
• dialog::backdrop, diyalog ile sayfanın geri kalanı arasındaki katmandır
  • Arka planı karartarak veya bulanıklaştırarak kullanıcının dikkatini diyaloga yönlendirebilir
  • Tarayıcı yerleştirdiği için kaydırma, sabit öğeler ve tarayıcı boyutu değişikliklerini doğrudan ele almanız gerekmez

Daha az JavaScript ile mümkün olan özellikler

• JavaScript’i azaltabileceğiniz daha çok özellik vardır
  • scroll-behavior: smooth ile yerel yumuşak kaydırma
    • Yalnızca prefers-reduced-motion: no preference uyduğunda kullanma koşulu eklenir
  • scroll-snap ile yerel carousel
  • position: sticky ile “in-view” öğeler
  • Konteyner sorguları
• Gelecekte eklenecek özellikler de var
  • Kaydırmaya dayalı animasyonlar
  • masonry.js olmadan grid-template-rows: masonry ile yapılan Masonry yerleşimi
  • Yeni selectlist öğesiyle tamamen stillendirilebilir select
  • JavaScript seçim kodlarının bir kategorisini azaltabilecek :has() seçicisi
• İlgili içerikleri Stop Using JavaScript for That: Moving Features from JS to CSS and HTML. sunum videosunda daha fazla görebilirsiniz
• Önceden doğrulanmış bir uygulamayı yeni bir yöntemle değiştirirken, özellikle kimseyi dışarıda bırakmamak için erişilebilirliği test etmek gerekir

[GN⁺]

Hacker News yorumları

• Bu yazıda eksik kalan nokta, böyle yerlerde JavaScript kullanılmasının nedeninin uyumluluğun daha iyi olması
  Yeni JavaScript transpile edilebilir, ama eksik CSS ya da HTML özelliklerini polyfill ile tamamlamak çok daha zor, bazı durumlarda imkânsızdır. Üstelik o polyfill de eninde sonunda JavaScript kullanır
  appearance için MDN’de bile, appearance: none için dahi kapsamlı test yapılması gerektiğine dair çok sayıda uyarı var. Yalnızca modern tarayıcıları destekliyorsanız daha az önemli olabilir, ama eski Safari sürümleri sanıldığından daha uzun süre ortalıkta kalıyor
  datalist, Firefox Android’de hiçbir şey yapmıyor; bende önerileri bile olmayan bir giriş kutusu gibi görünüyor
  Renk seçici güzel, ama aşırı derecede standart dışı olduğu için çoğu işletme açısından ölümcül. Sadece tasarımcılar şikâyet etmiyor; müşteri desteğinin kullanıcılara yardım etmesi de zorlaşıyor. Chromium sayfadan renk alma ya da rastgele renk seçme işlevi bile sunuyor, Firefox Android ise yalnızca gökkuşağı, gri tonları ve siyah-beyaz gibi seçenekler veriyor
  Yazının kendisi de details ve dialog arasındaki tutarsızlığı kabul ediyor. Bir gün bu özellikleri desteklemeyen ya da birbirleriyle tutarlı şekilde desteklemeyen tarayıcıların artık kullanılmamasını umuyorum; ama bir süre daha bu öğeler, desteklenen tarayıcıları tamamen kontrol edebildiğiniz yan projelerde kullanılacak gibi görünüyor

  • Renk seçicinin standart dışı olduğu görüşüne katılmak zor
    iPhone’da düğmeye bastığınızda gerçek sistemin yerel renk seçicisi açılıyor. İşletim sisteminin sağladığı, birçok uygulamada gördüğünüz tam da o denetim ve özel yapılmış bir seçiciye göre çok daha fazla tercih ederim
  • Uyumluluğun daha iyi olması, ancak tüm kullanıcıların JavaScript kullanması gerektiği varsayımıyla doğru
    JavaScript’siz web’i çok daha fazla tercih ediyorum; dizüstü bilgisayarın pil ömrünü de saatler mertebesinde etkiliyor. Bazı siteler bununla uyumlu değil; boş sayfa render ediyor ya da metni göstermek için JavaScript gerektiğinden yakınıyor
    Buna karşılık Amazon’un JavaScript’siz bir e-ticaret sitesi kopyası bile var; bu da böylesine büyük bir işin JavaScript olmadan da mümkün olduğunu gösteriyor
  • dialog öğesinin destek kapsamı artık epey derin ve 2021 dönemi Firefox ya da Safari kullanan birkaç yüzdelik kullanıcı için polyfill de gayet yeterli
    Modal yapıyorsanız şiddetle tavsiye ederim; erişilebilirlik iyileştirmesi harika
  • Müşteri desteğinin kullanıcılara yardım etmesinin zorlaşması büyük mesele
    Eski iş yerimde bu konuyu aktif biçimde tartıştık ve datalist gibi şeyler yerine JS implementasyonu kullanmaya karar verdik. Özellikle datalisti denedik, ama sonuçlar çok tutarsız olduğu için vazgeçmek zorunda kaldık
    Sonunda tarayıcılar arası tutarsızlık nedeniyle Chrome dışında desteği de kestik
  • Hayır. JavaScript başarısız olursa tamamen başarısız olur ve içeriğin kendisi ortadan kaybolur
    HTML örnekleri eski tarayıcılarda şekil olarak bozuk görünebilir, ama gerçek içerik yerinde durur. JS’de ise hiçbir şey yoktur. Erişilebilirliği tamamen bozar
    HTML ise ekran okuyucu en azından okuyabilir; JS ile oluşturulan içerik bunu engeller. JS, JS’i çalıştıramadığında hiçbir polyfill ya da başka JS, JS’i kurtaramaz. Daha en başından “çalışması” gerekir ki erişilebilirlik açısından kabul edilebilir olsun; o durumda da asıl tartışma anlamsızlaşır

• Datalisti bilmiyordum; en azından Chrome Android’de düzgün çalışıyor gibi görünmüyor
  Seçenekler, otomatik tamamlama önerilerinin çıktığı klavye alanında görünüyor: https://imgur.com/a/Ecb4503
  Mobil web arayüzlerindeki form kontrollerinde böyle bir yöntemi ilk kez gördüm; aynı alanı kullanan parola otomatik doldurma uygulamaları dışında görmemiştim
  Kötü değil. Özensiz yapılmış özel JS açılır listesini tuhaf tuhaf kaydırmaktan çok daha iyi, ama sıradan bir kullanıcının bunu nasıl kullanacağını anlayacağından emin değilim. Bu yüzden mobilde fiilen umutsuz görüyorum
  Firefox Android’de ise hiç desteklenmiyor: https://caniuse.com/?search=datalist

  • Tarayıcı üreticileri, datalist açılır listesine stil verme imkânı sağlayamaz mısınız?
    Referans: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
  • Bu tür çözümlerin yaygın biçimde yerleşmesinin uzun sürmesinin nedeni bu
    JavaScript oldukça iyi standartlaştırılmış durumda, ama HTML ve CSS görece daha az
  • input öğesine autocomplete="off" eklenince davranışın değişip değişmediğini merak ediyorum
    Her hâlükârda datalisti doğru düzgün kullanmak için gerekli. Aksi halde değer seçme geçmişi açılır listeye ekleniyor. Bunu Chromium’da gözlemledim
    Ayrıca varsayılan değer ayarlanmış olması gibi bazı durumlarda datalist hâlâ JS gerektiriyor. Geçici çözümleri ve tarayıcıya özgü tuhaf davranış notlarını yeni LibreOffice web sitesi kodunda derledim: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
    İyi haber şu ki Firefox geliştiricisi datalist davranışını iyileştirmeyi incelemeyi planlıyor; böylece liste tek tıklamayla gösterilebilir hâle gelebilir
  • Klavyenin üstüne baktınız mı?
    Benim durumumda seçenekler genelde kelime önerilerinin gösterildiği klavyenin üstündeki alanda görünüyor
  • datalist seçeneklerinin klavyenin içinde görünmesi son birkaç ayda ortaya çıkan bir değişiklik
    Eskiden “normal”di; sanırım biri sırf değiştirmiş olmak için değiştirmek istemiş

• scroll-behavior: smooth ile yerel yumuşak kaydırma kullanmayı lütfen yalnızca sınırlı durumlarda tercih etmek gerekir
  Sanıldığından daha fazla kullanımda iyi bir fikir değildir ve istenmeyen yan etkileri sık görülür
  scroll-snap ile yerel bir carousel yapılabildiği söyleniyor ama carousel hâlâ kötü bir fikir olduğu için scroll-snapin meşru kullanım alanı son derece sınırlı
  Kaydırma tabanlı animasyon kullanan sayfalar çoğu zaman bunu kaldırınca daha iyi olur

  • Bu yazının amacı belirli tasarım öğelerini kullanmayı buyurmak değil, bu tasarımları daha kullanıcı dostu biçimde nasıl uygulayabileceğini göstermek
    Yumuşak kaydırma iyi bir örnek. Yerel API, kullanıcının istediği anda bunu kesebilmesini sağlar. Çoğu JS uygulaması korkunç derecede takılır ve kullanıcıyı uğraştırır
    Tasarım tercihlerini istediğin kadar azarlayabilirsin ama “carousel hâlâ kötü” için gerçek bir neden sunmazsan dinlenmeyi beklemek zor
  • Ben de carousel’lerden nefret ederim
    Ama Amazon ana sayfası carousel’i belirgin biçimde kullanıyor ve bildiğim kadarıyla Amazon ana sayfa varyasyonlarını acımasızca A/B test eder. O zaman carousel’in testlerde iyi çıkmış olma ihtimali var; dolayısıyla evrensel ve nesnel anlamda gerçekten “kötü” demek muğlaklaşıyor
  • Yerel yumuşak kaydırma neden çoğu durumda iyi bir fikir değil?
    Genelde içindekiler tablosu tarzı anchor’ları uyguladıktan hemen sonra en azından ekliyorum
  • Her hâlükârda bunlar için JavaScript gerekmiyor

• 2023’te hâlâ formlar ve kullanıcının veri girdiği genel UX üzerine tartışıyor olmamız şaşırtıcı
  datalist ve renk seçiciyle ilgili yorumlara bakmak bile yeterli; bunun neden hâlâ çözülmüş bir alan olmadığını anlamıyorum
  Geçmişte XForms ile bunu tek seferde çözme girişimi vardı ama tarayıcılarda uygulanmadı
  Onun yerine neredeyse tüm CSS/JS bileşen framework’leri, farklı semantiklere sahip sınırlı form öğeleri kümelerini ayrı ayrı sunuyor

  • XML teknolojilerini reddetmenin sonucu olarak web, XML’in sunduklarının berbat sürümlerini sonsuza dek yeniden uygulamaya mahkûm kaldı
    Görünüşe göre ömrümüz boyunca temel UI kontrollerini kendimiz uygulayacağız
  • Zaten çözülmüş durumda. React içine koyup hayatına devam etmen yeterli
    “Çözülmedi” gibi görünmesinin tek nedeni, bazı insanların JavaScript’ten kaçınma konusundaki tuhaf takıntıları yüzünden yarı pişmiş alternatifleri zorla araya sıkıştırmaya çalışması
  • Formların “çözülmüş” olması ne anlama geliyor?
    Sıkıcı ve temel teknolojide kalacaksan zaten çözülmüş durumda. Ama React ile yeniden çözmekte, React hooks ile bir daha çözmekte ve sonsuza dek tekrar tekrar çözmekte ısrar edersen çözülmemiş olur
  • CSRF yüzünden, insanların yapabildiği ama bizim yapamadığımız birkaç şey var
    Niyet programatik olarak belirlenebilen bir şey olmadığı için bazı durumlarda havalı özelliklere sahip olamıyoruz
    Üzerinde son çalıştığım karmaşık formda, tarayıcının izin vermesi için tıklama olayının form gönderimini oldukça doğrudan tetiklemesini sağlamak zorunda kalmıştım
  • Birileri bir yerlerde formlarla birbirinden farklı şeyler göndermek istediği için formlar çözülmüş değil
    Bir web sayfası üzerinden renk göndermenin yolunu hiç istemedim

• JavaScript yerine details kullanırsan Ctrl+F onun içini arayıp açabilir
  JavaScript accordion’ları bu şekilde açılamaz

  • hidden="until-found" kullanırsan JS tabanlı accordion’larda veya başka gizli içeriklerde de bu mümkün olur; ne yazık ki şu anda yalnızca Chromium tabanlı tarayıcılarda var: https://developer.chrome.com/articles/hidden-until-found/
  • Aramaya izin verirken gizlemenin başka bir yolu var mı?
  • Belgeleri gözden geçirirken az önce benzer bir sorun yaşadım

• Çoğuna katılıyorum ama dialogu yeterince kullanmadığım için fikrim yok; datalistin ise dahili araçlar dışında geçerli bir seçenek olmadığını düşünüyorum
  Çirkin, yapabilecekleri sınırlı ve stil verilemiyor. “Sadece yerleşik özelliği kullanın” argümanlarının çoğundaki sorun bu. date picker da aynı
  Varsayılanı kötü olmakla kalmıyor, değiştirmek istesen de değiştiremiyorsun. Stil veya davranış değişikliğinde sayısız duvardan birine çarptığında, örneğin haftayı pazartesiden başlatmak istesen bile yapamıyorsun. O zaman seçenek genellikle JS kullanan tamamen ikame bir kütüphane oluyor
  Daha hafif seçenekler kullanmayı destekliyorum ve HTML > CSS > JS katmanlaşmasına da katılıyorum; ama hem iyi görünen bir UI hem de istediğin işlevleri elde etmek için bazen JS tek cevap oluyor

  • Arama önerisi kutusu uygularken datalistin işe yarayıp yaramayacağını düşündüm
    Girilen metinle sıkı biçimde başlamayan seçenekleri göstermek istediğim ana kadar iyi çalıştı. Örneğin girişte yazım hatası varsa seçenekler görünmüyor
    Tüm öğeleri zorla göstermenin bir yolu olmadığı için sonunda sıralı listeyi seçtim
  • Yerleşik semantik markup’ı JS ile genişletme yaklaşımının geleceğe dönük bir yöntem olduğunu her zaman hatırlamakta fayda var
    Web geliştirmeye başladığımda değişim en fazla 10 yıl sürüyordu. IE6 da hepimizi geride tutuyordu ama o dönemde w3c de epey güçsüzdü. Şimdi değişim hızlı
    Gelecek yıl üç büyük tarayıcıda datalist stil verme işlemi öneksiz mümkün olabilir; ama özel JS çözümüne bağlı kalırsan işletme yeniden inşa maliyetini ödemeyecektir
    Yerel özellikleri JS ile genişletirsen destek yeterli hâle geldiğinde düşük maliyetle JS’yi kaldırabilirsin. Yerel kontrollerin kabul edilebilir olduğu yerlerde şimdi kullan, JS’yi de polyfill gibi uygula
  • Haftanın başlangıç günü veya input[type=date] için sıkça önerilen özelleştirmelerin çoğunda kontrolün geliştiricide olmaması aslında daha iyi
    Gösterilecek uygun takvim locale’e bağlı olmalı. Kullanıcının platformu, zaten kullanıcının etkin biçimde kullanma ihtimali en yüksek şekilde ayarlama ve gösterme işlevine sahip
    Platformun tarih seçicisi, kendi yaptığın tuhaf şeyden daha iyidir

• O geçiş düğmesi gerçekten iyi
  Bu yazıya frontend meme geliştiricileri öfkelenmiş gibi görünüyor ama ana nokta doğru. Neden bu kadar çok aptal site JS ile yapılıyor? İnsanlar HTML gibi tek bir standardı izlese her şey tutarlı olabilir; erişilebilirlik ya da çeviri gibi şeyler de kolayca uyarlanabilir
  Bugünlerde bir siteye girdiğinizde, her şeyi tek bir sayfada dinamik olarak yükledikleri için geri düğmesi bile çalışmıyor

  • İnsanlar HTML gibi tek bir standardı izlese bile, tarayıcı üreticilerinin bunu tutarlı biçimde uygulaması gerekir
    Ayrıca yeni bir özellik geldikten sonra yeterince yaygın desteklenip işe yarar hâle gelmesi yıllar sürebilen, “insanların güncellemesini bekleme” sorunu da hâlâ var
    Kötü uygulamalar ve karmaşık JavaScript düzenekleri çok olduğu konusunda genel olarak katılıyorum. Dinamik içerikte bile geri işlevini korumak için epey standartlaştırılmış çözüm var; popüler web framework’lerinin bunu varsayılan olarak desteklediğini biliyorum
  • Gerçekten öfkeleniyorlar mı?
    Üst yorumları okudum ama öfke denebilecek pek bir şey görmedim; yalnızca tarayıcı desteği konusunda makul noktalar dile getiren insanlar görüyorum

• Doğru yönde atılmış bir adım olsa da CSS de Philip Greenspun’ın “artistes” dediği kişilerin okunması zor sayfalar yapmak için kötüye kullandığı başka bir araç
  Gemini destekçisi değilim ama temelde yerleşim ve tipografinin tüm yönleri tarayıcıya geri dönmeli ve kullanıcı tarafından kontrol edilmeli. Tasarımcılar bunun kendilerine güvenilip bırakılamayacağını durmaksızın gösterdi

• Niyeti seviyorum; switch de güzel, summary/details da bazen işe yarıyor
  Ama datalist öğesi, oyuncak ya da prototip ötesi kullanımlar için neredeyse hiç gerçekçi bir seçenek değil

• Benim sevdiğim “JS olmadan CSS yeterli” şeyler sidebar drawer ve carousel
  DaisyUI adlı TailwindCSS bileşen kütüphanesinde de doğrudan kullanılabilir bileşenler var
  https://daisyui.com/components/drawer/
  https://daisyui.com/components/carousel/

  • Drawer’ı ekran okuyucuya nasıl bildiriyorsunuz?
    Drawer ve sayfada beliren diğer içerik bildirilmeli; kontrol edilen hedefin yanında aria-expanded durumu olmalı
    Bu hâlâ gerçek bir soru. Bir yolu olabilir ya da geliştiriciler collectively bunun önemli olmadığını düşünüyor olabilir. Denetçiler aynı fikirde olmayacaktır gerçi
  • Böyle framework’leri gördüğümde başta hep heyecanlanıyorum ama test ettiğim diğer tüm framework’ler gibi DaisyUI’nin de iOS Safari ve diğer tarayıcılarda çeşitli sorunları var
    Bu framework yazarları, tarayıcılar genelinde gerçekten çalışır hâle getirmek için ne kadar test gerektiğini ciddi biçimde hafife alıyor gibi
    Bu kadar çok bileşen varken, üstelik tema desteği de olunca, mevcut temaları ve uygulamaları bozmadan düzeltmenin mümkün olup olmayacağı bile belirsiz
  • components/carousel/ içindeki “Snap to [start|center|end]”i ilk kez görüyorum
    Snap denen şey tam olarak ne ve nasıl çalışıyor? Ekranım parmak tıklamasına tepki vermiyor
    Bilinmeyen etkileşim biçimlerinin, bir UI öğeleri kütüphanesini önermek için iyi bir gerekçe olduğunu sanmıyorum