HTML’e Bahse Girmek

• Büyük dil modeli tabanlı yapay zekanın yaygınlaşmasıyla birlikte, insanların gördüğü ekran kadar makinelerin okuyabildiği semantik HTML’in değeri de artıyor
• Büyük sosyal medya platformlarının kapalı bahçeleri, veri taşınabilirliğini ve birlikte çalışabilirliği engelliyor; fediverse, Threads ve Bluesky gibi dağıtık girişimlerin de genel kullanıcıları çekmek için motivasyonu zayıf kalıyor
• Modern HTML, <details>, <dialog>, çeşitli <input> türleri gibi web uygulamalarının ihtiyaç duyduğu temel UI öğelerinin önemli bir kısmını zaten sunuyor
• Tarayıcının varsayılan stilleri ve reader mode kullanılarak aşırı CSS ve JavaScript bağımlılığı azaltılabilir; doğru etiketler makine tarafından okunabilirliği ve mobil giriş deneyimini iyileştirir
• RSS hâlâ yaşıyor ve ChatGPT benzeri arayüzlerin veri erişim yöntemi olarak öne çıktığı bir akışta, reklam odaklı arayüzlerden ziyade yapılandırılmış HTML daha pratik bir temel olabilir

---

Web’in temel veri arayüzü olarak HTML

• Büyük dil modeli tabanlı yapay zekanın ortaya çıkışı, semantik HTML’in önemini yeniden öne çıkarıyor
• İnternetin özü, insanların dünyayla etkileşim kurması için gerekli veriyi iletmektir; ancak HTML/CSS/JavaScript’in sunduğu serbestlik, veri erişimini sınırlayan iki taraflı bir etki de yaratabiliyor
• Büyük teknoloji şirketlerinin sosyal medya platformları, açık ve erişilebilir veri formatları ile API’ler yerine kullanıcıları kapalı platformlar içinde tutuyor
  • Platformlar arası birlikte çalışabilirlik fiilen zorlaşmış durumda
  • Şirketlerin verinin kolay taşınmasını istememesi, sorunu daha da karmaşık hâle getiriyor
• Son dönemde sosyal medyadaki istikrarsızlık, fediverse gibi dağıtık platformlara ilgiyi yeniden artırıyor
  • Meta’nın Threads’i ve Jack Dorsey’nin kurduğu Bluesky, daha geniş fediverse ile birlikte çalışabilir olmayı öne çıkarıyor
  • Ancak genel kullanıcılar çoğu zaman yalnızca bu nedenle yeni bir sosyal medya platformu seçmiyor
• Daha önce kendini kanıtlamış bir çözüm olarak HTML’e yeniden bakmak gerekiyor
  • Geçmişte, HTML içeriğinin tarayıcıda kötü görünmemesi için yoğun biçimde CSS kullanmak gerekiyordu
  • Bugün çok sayıda modern HTML öğesi eklendi ve bunlar, modern web uygulamalarının ihtiyaç duyduğu UI bileşenlerinin büyük bölümünü sağlıyor
  • Reader mode, stil vermeye harcanan zamanı boşa çıkarabilir; ama buna olumlu da bakılabilir
• Doğru etiketler, makinelerin kolay okuyabileceği bir biçim sağlar
  • Bu, yalnızca tasarım süresinden tasarruf etmekten daha güçlü bir gerekçedir
  • RSS yaşamaya devam ediyor
  • ChatGPT gibi arayüzlerin, insanların verilere erişimde gelecekteki yöntem hâline gelmesi de mümkün

Faydalı veya yeni gözle bakmaya değer HTML öğeleri

• MDN’nin tüm HTML öğeleri listesine göz atmaya değer
  • Aşağıdaki örnekler, ek stil olmadan yalnızca tarayıcının varsayılan stillerini kullanır
  • Tarayıcıya göre çok farklı görünebilir ya da hiç desteklenmeyebilir
• <abbr>: kısaltmaları sarmalayan öğe
  • Stil uygulanarak vurgulanabilir
  • Esas olarak makine tarafından okunabilirlik açısından faydalıdır
• <datalist>: giriş adayları listesi sunan öğe
  • Typeahead benzeri bir UI oluşturabilir
  • Yerleşik doğrulama olmadığı görülüyor
  • Safari’de option etiketi kapatılmalıdır; kapatılmazsa çalışmaz
• <details>: açılır-kapanır açıklama öğesi
  • Küçük bir dropdown biçiminde kullanılabilir
  • Güçlü biçimde stillendirilebilir de
• <dialog>: diyalog kutusu öğesi
  • Düğmeler, formlar, öznitelikler ve JavaScript ile açılıp kapanabilen yerleşik bir öğedir
  • Tam olarak modal ile aynı şey değildir, ama bir modal yapılacaksa iyi bir temel olabilir
  • Sonraki öğelerin üzerinde render ediliyor gibi görünüyor
• <i> ve <em>
  • Bu iki öğe arasındaki farkı bilmek gerekir
• <iframe>
  • Örnek listesine dahil edilmiş, ancak şaka yollu ele alınıyor
• <input>: form giriş öğesi
  • Girişler için uygun etiket ve tür kullanılmalıdır
  • Mobilde işletim sistemi bağlama göre farklı klavyeler açtığı için giriş türünü belirtmek önemlidir
  • Zamanla ilgili çeşitli girişler sayesinde ayrı bir JavaScript date picker ihtiyacı azaltılabilir
  • Örnek olarak color, range, datetime-local girişleri veriliyor
• <mark>: metin vurgulama öğesi
  • Varsayılan olarak Safari’de sarı vurguyla gösterilir
• <meter>: ölçüm değeri gösterme öğesi
  • Safari’de ayarlanan parametrelere göre kırmızı, sarı ve yeşil olarak gösterilir
  • optimum değeri ayarlanabilir
  • 60fps müzik görselleştirme demosu için faydalı olabilir
• <progress>: ilerleme göstergesi öğesi
  • Sabit bir değer ya da belirsiz durum verebilen yerel HTML ilerleme çubuğudur
  • Safari’de pencere aktifken mavi, aktif değilken gri görünür
  • Varsayılan olarak sistem vurgu rengini izler ve CSS’in accent-color özelliğiyle ayarlanabilir

[GN⁺]

Hacker News yorumları

• HTML’in kapalı ekosistem bağımlılığına çözüm olduğu fikri tuhaf. Bu tür kapalı servisler zaten HTML kullanıyor; bahsedilen semantik öğelerin bir kısmını ve daha gelişmiş ARIA semantik özniteliklerini de kullanıyorlar.
  ChatGPT gibi arayüzlerin insanların veriye erişim geleceği olduğu iddiasına gelince, yapay zeka sistemlerinin özü, girdiyi işlemek için özel “makine tarafından okunabilir” açıklamalara ihtiyaç duymamasında yatıyor. ChatGPT ve sonraki modeller, insanların yaptığı gibi sıradan web sitelerinde gezinebilir ve bir paragraf grubunun açık bir işaretleme olmadan “liste” olduğunu fark edebilir.
  Yazarın anlattığı şey sonuçta HTML semantik öğeleri aracılığıyla sunulan bir API’ye daha yakın. Ama bir API varsa, otomatik veri erişimi için büyük dil modeline gerek yok; Beautiful Soup kullanan sıradan bir Python betiği yeterli olur ve yalnızca yerelde çalışması gibi bir avantajı da vardır.

  • Bu, meseleyi fazla daraltmak gibi görünüyor. Bir yanda “HTML” var, bir yanda da kullanıcının 10 saniye boyunca okumaya çalışmasından sonra nihai DOM’u ancak belirlenen web siteleri var. Bu iki uç arasında, tarayıcı özelliklerini ne kadar kullanmanız gerektiği açısından büyük farklar var.
    Sonuçta iyiyi kötüden ayıran şey uygulama karmaşıklığı. Her araç iyi ya da kötü kullanılabilir; acemi biri daire testere ve dolu bir bataryayla büyük bir kaza çıkarabilir. Usta ise aracı hiç kullanmayıp kenarından dolanmayı, yani iş gereksinimlerine karşı çıkmayı seçebilir.
    Son dönemde yaptığım web siteleri, yaptıklarım arasında uyumluluğu en yüksek olanlar. Artık web socket kullanmıyorum ve JavaScript’in sunucuyla parça parça konuştuğu bir yaklaşıma dayanmıyorum. JavaScript’i tamamen kapatsanız bile ürünün yaklaşık %80’ini kullanabiliyorsunuz. Bu tür mühendislik tercihlerinin kapalı ekosistem bağımlılığına nasıl çözüm olmadığını anlamıyorum.
  • “ChatGPT ve sonraki modeller, insanların yaptığı gibi sıradan web sitelerinde gezinebilir” sözü bana henüz doğru olmayan bir iddia gibi geliyor. Yine de mümkün olduğunu varsayarsak ilginç.
    Büyük dil modelleri metin, kaynak kodu vb. üzerinde eğitiliyor; ama çıkarım mekanizması denebilecek şeyden yoksunken bir DOM ağacına bakıp bunun ne olduğunu ve ne yaptığını gerçekten anlayabilir mi emin değilim. DOM metin değildir; bundling ve bileşenleştirmenin sonucu olduğu için iyi yapılandırılmış kaynak kodu sayılması da zor. Bu, neredeyse “büyük dil modeli rastgele bir .exe’ye bakıp onu hemen entegre edebilir” demeye benziyor.
  • Yazının niyetini, JavaScript’e özel div yığınları yerine ya da bunlara ek olarak HTTP üzerinde makine tarafından okunabilir semantik içerik kullanmak şeklinde okudum. Böylece yeni dalga büyük dil modelleri gibi otomatik ajanlar, sayfayı render etmek için headless tarayıcı çalıştırmadan önemli ayrıntıları kolayca çıkarabilir.
    Benim de benzer bir ilgim var; amacım crawling ve yeni arama motorları. Her sayfayı indekslemeden önce headless tarayıcıda çalıştırmak gerekiyorsa, yeni bir arama motoru için giriş bariyeri çok daha yükselir.
  • Yerinde bir tespit. İronik biçimde, semantik işaretlemenin başlıca avantajı artık insan geliştiricilerin stillendirme ve kontrol yapmasını kolaylaştıran bir soyutlama hâline gelmiş gibi görünüyor.
  • ChatGPT gerçekten bunu yapabiliyor mu? Pratikte böyle mi yapıyor?

• Yazının ilk cümlesi “Büyük dil modeli tabanlı yapay zekanın ortaya çıkışıyla semantik HTML her zamankinden daha önemli hâle geldi” diyor; oysa bence “Büyük dil modeli tabanlı yapay zekanın ortaya çıkışıyla semantik HTML her zamankinden daha az önemli hâle geldi” çok daha savunulabilir bir cümle olurdu.
  Semantik web başarısız oldu ve onun yerini, Google’ın o dönem için en üst düzey yapay zekayı kattığı çeşitli sezgisel yöntemlere muazzam para harcaması aldı. Yapay zeka iyileştikçe, gelişigüzel hazırlanmış karmakarışık içeriklerden bile bilgi çıkarma becerisi artıyor; böyle bir karmaşa yeterliyse insanların harcayacağı emek de o kadarla sınırlı kalır. İlkesel olarak, sonunda hem semantik web hem de sezgisel yöntemler yığını yapay zeka tarafından ikame edilir.
  Başta yalnızca LLM deyip sonrasında genel terim olan AI’a geçmesi de önemli. Büyük dil modelleri yapay zekanın tamamı değil; şu anda gözde olan dallardan sadece biri ve son gözde dal da olmayacak. Önümüzdeki onlarca yıl için büyük dil modellerinin yapay zekanın nihai cevabı olduğunu varsayıp öngörü yapmak iyi değil.

  • Yapay zekanın semantik HTML ve ARIA’ya dayalı web erişilebilirliğini de çözeceğini mi düşünüyorsun? Değilse, web içeriğinin erişilebilir olmasını sağlamak için hâlâ insana ihtiyaç var; bu durumda semantik HTML önemini korur.
  • Büyük dil modellerinden sonra arama motoru optimizasyonunun nasıl görüneceğini merak ediyorum.
    Amaç, içeriğin ilgili bölümlerinin yeterince iyi indekslenip sıralamada yer almasıysa, semantik HTML’i tamamen benimsemek için yeterli teşvik olmadığı söylenebilir.
    Hedef “sıralamada yer almak”tan “büyük dil modelinin içeriğin nüansını ve dokusunu olabildiğince çıkarmasını sağlamak”a dönüşürse, belirli öğeleri daha iyi kullanma teşviki artabilir. Bunu yapan web siteleri, büyük dil modellerinin çıktıları üzerinde daha fazla etkiye sahip olabilir.
    Bu bana, duyulacak kadar yüksek sesle konuşmak ile anlaşılacak kadar açık konuşmak arasındaki fark gibi geliyor.
  • schema.org ve Wikidata/Wikipedia hâlâ Google’ın zengin arama sonuçlarının çoğunu desteklemiyor mu?
    Bard’ın dahil edildiği yeni sonuç sayfasını duyurduklarını işittim; ama reklamları görmezden gelme alışkanlığımdan mı, yoksa bölgeme henüz gelmediğinden mi bilmiyorum, görmemişim gibi geliyor, bakmam gerekecek.
  • Yapay zeka sihir gibi hissettiriyor. İnsanların örüntü tanıma becerisinin her zaman epey benzersiz ve kopyalanması zor olduğunu düşünmüşümdür. Bir web sitesindeki karmaşayı gözden geçirip bir şekilde veri çıkarırken bu beceriyi kullanıyoruz.
    Zihnen semantik web tarafına daha yakındım; ama makineler o karmaşayı az çok anlayabiliyorsa, neden özellikle uğraşalım ki argümanı doğru.
  • Veri kaynakları oluşturup yapay zekanın bu kaynakları kullanmasını sağlamaya çalışan projeler asıl noktayı kaçırıyor. Yapay zekanın kendisi veri kaynağıdır.
    Bilgi grafikleri ya da başka veri varlıklarının, yapay zekanın “gerçek” bilgiyi aramasına yardımcı olabileceğini savunan projeler de var. Kişisel olarak, yapay zekanın kendi veri varlıklarını oluşturmasını sağlayacak yöntemler geliştirmek daha iyi olur diye düşünüyorum. Sinir ağının ağırlıkları da bu varlıklardan biri.
    Hakikat meselesi hâlâ çok zor. Bir bilginin başka bir bilgiden daha güvenilir olduğunu yapay zekaya nasıl anlatabiliriz? Elbette insanlar için de aynı sorun geçerli.

• Bu HTML öğelerinin çoğunu neredeyse hiç duymamıştım; bu epey üzücü. Çünkü bunlar, “her şey için JavaScript gerekir” ekosistemini sona erdirmeye ciddi ölçüde yardımcı olabilir
  En azından JavaScript’i asıl amacına daha yakın bir yere, yani biraz süsleme veya etkileşim ekleme aracı konumuna geri döndürebilir. Tüm markup’ın yerine geçen ve tüm DOM’u yöneten şey olması gerekmez
  Hayalimdeki tarayıcı belki visurf https://sr.ht/~sircmpwn/visurf/ gibi bir şey; içindeki Netsurf motorunun da bu öğeler dahil modern HTML+CSS’i destekleyecek şekilde güncellenmiş hâli. Böyle bir tarayıcıyla neredeyse JavaScript’siz küçük web kurulabilir gibi geliyor. Erişilebilirlik daha iyi olur; çünkü ekran okuyucuları, sistem temalarını, kısayolları vb. daha az bozar. Yerine konulabilir ağır JavaScript düzeneklerinden çok daha az kaynak kullanır ve bugünün orta seviye web uygulamalarından beklenenlerin çoğunu da mümkün kılabilir gibi görünür. WebGL gibi şeyler için Firefox’u açarsın; ama örneğin bir Matrix istemcisi bile websocket’ler ve uçtan uca şifreleme için biraz JavaScript eklenerek yapılabilir

  • Bu tür yerleşik bileşenlerin genel sorunu tema uygulamanın zor olması. Modern bir uygulamanın ortasında Windows 7 tarzı bir bileşenin fırlayıp çıkması inanılmaz rahatsız edici olur
    Genişletilebilirlikleri de neredeyse yok; biraz karmaşık bir şey yapman gerektiğinde sonunda onu bırakıp JavaScript’le baştan başlamak zorunda kalırsın. O zaman en baştan JavaScript’le başlamak daha iyidir; o taraf düzgün çalışır, tam kontrol verir ve her sistemde aynı davranır
    Sonuçta bu ek bileşenler, tüm tarayıcıların uygulamak zorunda olduğu ama kimsenin kullanmadığı bir şişkinlik olarak kalır
  • datalisti ilk gördüğümde “vay, oyunun kurallarını değiştirir” diye düşünmüştüm. Davranışı tarayıcılar arasında aynı, ama görünümü tamamen tarayıcıya özgü ve CSS ile stillendirilemiyor
    Bazen yalnızca verinin metni görünür, bazen metinle birlikte value özniteliği de görünür. Bu yüzden “Atlanta”yı seçmek yerine “234290780 Atlanta”yı, yani ID ile değeri birlikte seçmiş olursun
    Tıklama davranışında da ID’yi doğrudan alamazsın; tamamını alıp ID’yi ayrıştırman gerekir. Sanki terk edilmiş bir öğe gibi hissettiriyor
  • Şunu sevebilirsiniz: http://youmightnotneedjs.com/
  • Genel fikre karşı değilim, ama bu öğeler çok uzun zamandır var. HTML eleştirisinin ciddiye alınması için temel şeyleri bilmek gerektiğini düşünüyorum
    Yazı MDN’ye bağlantı veriyor; MDN kısa başvuru materyali olarak en kullanışlı kaynaklardan biri. Elbette WHATWG HTML spesifikasyonu da var; fazla kapsamlı gelirse WHATWG HTML 2021·2023 snapshot’ları için SGML DTD biçiminde söz dizimi ve eski HTML 5.x ailesi söz dizimleri de var
    [1]: https://sgmljs.net/docs/html200129.html
  • https://qutebrowser.org

• Semantik web’e inanmak istiyorum; tarayıcıların iyi varsayılan modüller ve fena olmayan varsayılan stiller sunabileceğine inanmak istiyorum, ama şu anda durumun böyle olmadığını kabul etmekten başka çare yok
  Bir inputa etiket eklemek gibi basit bir şeyde bile önce bunun neden bir öznitelik olmadığını düşünmek gerekiyor; sarmalayıcı olarak mı kullanmak gerekir, yoksa for= özniteliğine sahip bir kardeş öğe olarak mı durmalı, bundan emin olmak da zor. Bu sadece buzdağının görünen kısmı. Her etiket için tüm geliştirme tarihini öğrenip günümüzde doğru yöntemin ne olduğunu yeniden araştırmak gerekiyor
  İyi şeylere sahip olabilirdik, ama artık sakinleşip bırakmak gerekiyor gibi

  • Hangi aracı kullandığını bilmediğim için belirli bir kişiye yönelik söylemiyorum, ama web geliştiricileri React, Tailwind vb. öğrenmeye harcadıkları zamanın yalnızca bir kısmını HTML öğrenmeye ayırsaydı web çok daha iyi durumda olurdu
    Elbette tuhaf kısımlar ve pürüzlü kenarlar var; ama her web geliştiricisi semantik HTML’den azami ölçüde yararlanmayı bilseydi tarayıcıdaki JavaScript çok daha az olur, erişilebilirlik hataları azalır ve spesifikasyonun bu tuhaflıkları düzeltmesi ya da değiştirmesi gerektiğinde muhtemelen daha çok göz bunların üzerinde olurdu
  • Girdi etiketi bir HTML özniteliği olsaydı formlar çok daha az esnek olurdu. İki görsel öğeyi tek bir öğede birleştirirdi ve görüntüyü ayarlamayı zorlaştırırdı. Örneğin solunda sağa hizalanmış etiketi olan bir girdi ya da sağında etiketi olan bir checkbox düşünün
    label özniteliği düz metin içerik anlamına gelirdi; bu da fazla sınırlayıcı görünüyor
    HTML, onlarca yıldır kullanılan bir şey olarak karmaşık bir tarihe ve birçok katmana sahip. Yine de son dönemde çok büyük değişmedi ve MDN sayesinde HTML5 ile nelerin mümkün olduğunu yeterince öğrenmek, gerektiğinde de daha derine inmek kolay
  • Benim durumda neredeyse her zaman label etiketini input etiketinden sonra koymak istiyorum. Böylece CSS pseudo-class’larıyla girdi durumuna göre etiketi seçip stillendirebiliyorum
  • Her etiketin anlamını öğrenmek zorunda olmak, her türlü semantik etiketleme sisteminin özünde olan bir şey. Bu fikir hoşuna gitmiyorsa semantik web fikriyle temelden uyuşmuyorsun demektir
    Elbette herhangi bir yayınlama sistemini, hatta herhangi bir sistemi etkili kullanmak için sunduğu temel öğeleri nasıl kullanacağını öğrenmek gerekir. Yani bu yalnızca semantik web’e özgü bir sorun değil

• Go HTML şablonlarını debug ederken detailsi çok kullanıyorum
  {{if .DevMode}} ile geliştirme modundayken verileri içine koyarsan kapalıyken sayfayı fazla bozmadığı için göze batmaz; gerektiğinde açınca tüm içeriği görebilirsin

  • Mümkün olduğunda details öğesini biraz kötüye kullanıyorum. Çok temiz bir şey; neden daha çok kullanılmadığını anlamıyorum
  • Web sayfalarında açılıp kapanabilen menüler gibi pek çok amaçla kullanılabilir
    GitHub Markdown’da da kullanılabiliyor; örnekler veya satır içi açıklamalar için kullananlar da var

• Okumalar ve interaktif demolar iyiydi
  Flutter’la birkaç yıl uğraştıktan sonra yine aynı sonuca vardım. Bahsi HTML’e oynamak gerek
  Astro / Tailwind / Daisy UI / Alpine.js kombinasyonu, basit sunucu tarafı render’ı çok kullanan ve istemci tarafı tepkiselliğini biraz serpiştiren HTML siteleri yapmak için iyi
  Ortaya çıkan şey basit ve düzgün HTML dosyaları; masaüstü web tarayıcılarında ve mobilde sarmalanmış webview’lerde iyi görünüyor ve iyi çalışıyor. Uygulamam fiilen statik olduğu için CDN’de cache’leniyor, çevrimdışı da çalışıyor ve kaynağı görüntülemek hata ayıklamayı kolaylaştırıyor

  • Çeşitli gösterişli framework’ler ve platformlar denedikten sonra sonunda yine Alpine.js ve Tailwind kullanan statik bir siteye döndüm. Şimdiye kadar verdiğim kararlar arasında açık ara en iyisiydi
    En güzel yanı, yeni bir geliştirici React, Angular, PHP ya da Python tarafında olsun, 100 satırlık build dosyasına yaklaşık 3 dakika bakınca anlayacağından emin olabilmem. Gerçekten basit olması güzel
  • Flutter’la web çıktısı almanın kâbusa yakın olduğunu düşünüyorum. Son baktığımda render işlemi canvas üzerinde yapılıyordu ve hiç markup yoktu
  • Daisy UI’nin faydasını anlamama yardımcı olabilir misiniz? Eski usul class+stylesheet kullanımını Tailwind adlı ek bir adım üzerinden yapıyormuş gibi görünüyor
  • Evet, Astro ve islands architecture ile çalışmak gerçekten keyifli

• Semantik web’in sorununun, ne kadar kolaylaşırsa kolaylaşsın geliştiricilerin onu düzgün kullanmayı reddetmesi olduğunu düşünüyorum. Tarayıcı eklentim main etiketini kullandığı için bu etiketi dikkatle izliyordum; MDN belgeleri ne yapılması gerektiği konusunda çok net ve belgenin kendisi de iyi kullanım örnekleri gösteriyor. Ama bunu düzgün kullanan site sayısı çok az
  Hatta gösterişli profesyonel siteler bile navigasyon, footer gibi şeyler dahil tüm sayfa içeriğini main etiketinin içine sarmalayabiliyor. Bu etiket yalnızca sayfanın ana içeriği için kullanılmalı
  Bu kadar basit bir öğeyi bile düzgün kullanamıyorsak diğer öğelerden pek beklentim yok

  • HTTP fiillerini yanlış kullanan geliştiricilerle aynı türdenler
    Böyle şeyler sözleşmeymiş gibi davranmamalı
  • p etiketini paragraf için kullanan geliştiricilerin kelimenin tam anlamıyla hepsi onu doğru kullanmış oluyor. class="card" gibi şeylerden farklı
    Teknik kavrayışı yüksek bu kadar çok kişinin semantik web’in işe yaramazlığından ya da başarısızlığından yakınmasını anlamıyorum. Kulağa “Keşke otomobil başarılı olsa, uzun mesafe yolculuk rahatlayacak” demek gibi geliyor
  • İlk akla gelen çözüm daha sıkı doğrulama. Yapı doğru değilse tarayıcının render etmeyi reddetmesi gibi
    Ama böyle bir dönem vardı. HTML4 öncesindekiler genel olarak öyleydi ve bu daha kötüydü
    Bu yüzden geliştirici araçlarının yanlış kullanımda uyarı ya da hata vermesi daha iyi olabilir
  • Düzgün kullanmak için hiçbir teşvik yok. Ben de düzgün kullanmaya çalışıyorum ama her öğenin ne olması gerektiğine karar vermek için harcadığım zaman dışında hiçbir fark olmadı

• Buradaki birçok yorumun bu yazıyı JavaScript karşıtı bir yazı olarak görmesi ilginç. Bana göre ise bunlar, modern enterprise uygulama frontend’lerinde kullandığımız TypeScript merkezli framework’lerle birlikte kullanıldığında çok faydalı olacak araçlar gibi görünüyor. Çünkü HTML’in native araçları oldukları için bir sürü şey talep etmiyorlar
  Örneğin meter etiketi, bugün işe gittiğimde React’te kullandığımız tüm loading modüllerinin yerini alacak gibi görünüyor. Çünkü şu an kullandıklarımızdan çok daha iyi
  İnsanları yanlış anlamış ya da yazıyı yanlış okumuş olabilirim ama bugün büyük uygulamalarda olduğu gibi frontend’in neredeyse tamamı TypeScript olsa bile bu çok ilginç

  • Benim umudum, bunların dev JavaScript kod yığınlarının yerini alması. JavaScript’siz web’in ne yazık ki bir hayal olduğunu biliyorum ama en azından büyük parçaları kaldırıp sistemin yönlendirebileceği ve şekillendirebileceği daha standart bir kullanıcı deneyimi oluşturabiliriz
    Eskisine göre çok daha az JavaScript’le yapılabilen yeni uygulamalar ortaya çıkıyor. Mevcut enterprise TypeScript uygulamalarında bu yerinde yükseltme olabilir; ama umut, yeni uygulama geliştirmede bu tür enterprise framework’lerin kendisinden kaçınabilmek. Hayal kurabiliriz, değil mi?

• Web geliştirmeyi tamamen küçümsemek istemem ama gerçekten berbat. Ham HTML’den betik dillerine ve framework’lere kadar yıllardır bununla uğraştım; önemsiz bir şeyi yapmak için harcanan zaman bana muazzam bir beyin israfı gibi geliyor.
  Tatile gittiğimde sadece nerede yiyip içeceğimi ya da gün içinde nerelere uğrayabileceğimi bulmak istemiştim; ama sitelerin çoğu karmakarışık, eski ya da güncellenmemişti. Bir kez yapılıp unutulmuş hâlâ çok site var. Bütçeleri kısıtlı olduğu için güncellemeye güçleri yetmiyor ya da güncellemek teknik olarak fazla zor geliyor olmalı.
  Sitenin karmaşıklığı felce yol açıyor. Basit metin ve görsellerden oluşan birkaç sayfa yeterliyken, gereksiz yere aşırı tasarlanmış şeyler muazzam CPU çevrimleri yakıyor. Güvenlik güncellemeleri gerektiren hazır bir CMS’in orasını burasını değiştirerek yapılmış olma ihtimali de yüksek.
  Geçenlerde bir sinema sitesine bakıyordum; o hafta gösterimde olan birkaç filmi gözden geçirmek bile neredeyse imkânsızdı. Bir elektronik tabloya koysalardı daha okunabilir olurdu diye düşündüm; gerçekten de API’den JSON’u indirince onun daha okunabilir olduğunu gördüm.
  Çoğu, domuza ruj sürmek gibi yorucu bir ambalajdan ibaret. Facebook’un başarılı olmasının nedenlerinden biri kolay onboarding, bir diğeri de fotoğraf paylaşımını kolaylaştırmasıydı. WhatsApp ve Instagram için de aynı şey geçerli. Yayın yapmak kolay olmalı. Basit FTP de kolay sayılır ama sıradan insanlar için kullanılabilirlik sürecinde tuhaf bir kopukluk var. İnsanlar sürükle-bırak, yükle, bırak ve unut, kolay düzenleme istiyor. Veriyi tüketmek isteyenler ise sonunda öz olanı istiyor: verinin kendisini.

  • Veriyi tüketmek isteyen insanların sadece temel veriyi istediğini sanmıyorum. Ortalama HN okuru için bu doğru olabilir ama ortalama insan için değil.
    İnsanların istediği şey iyi stillendirilmiş ve kullanılabilir web sayfaları. Sorun, etkili ve yetenekli kullanıcı deneyimi tasarımcılarının yeterince olmaması ve şirket paydaşlarının da düzgün bir UX sezgisinden yoksun olması.
    Bu yüzden ortalama bir şirketin karşılayabileceği beceriksiz UX yerine sadece temel veriyi sunmak, ortalama kullanıcı için daha iyi bir durum hâline geliyor. Tercih ettikleri için değil, daha iyi olduğu için.
    {kötü UX} << {ham veri} < {iyi UX}
    WordPress’in bulduğu kestirme yol, profesyonel stiller ve temalar oluşturup kullanıcıların bunları satın alarak uygulamasını sağlamaktı. Ama paydaşların kötü zevkini de çözemiyor.
    Bence Facebook, profesyonel ve standartlaştırılmış bir UX’i dayattığı için başarılı oldu. {insanların verisi} + {profesyonel ve standartlaştırılmış UX} = {zafer}. İlk dönem Facebook UX’inden hoşlanmayabilirsiniz ama amatör işi olduğunu söylemek zor. MySpace veya Geocities gibi yerlere dair genel algı bunun tersiydi.
  • WhatsApp’tan söz edilen kısım tam noktayı yakalıyor. Bulunduğum Afrika ülkesinde WhatsApp o kadar popüler ki mobil operatörler WhatsApp veri paketleri bile satıyor.
    Tel örgü gibi bir şey arıyorsam, önce dahil olduğum WhatsApp gruplarına, aile/mahalle/lise arkadaşları gruplarına soruyorum. Genelde birkaç numara alıyorum; hizmet sağlayıcıyla WhatsApp üzerinden iletişime geçince en güncel bilgiyi alıyorum.
    Bu hizmet sağlayıcıların güncel bir web sitesine güçleri yetmez. WhatsApp’ta profile katalog koyma özelliği de var ve ücretsiz işletme hesapları için.
  • Bu yüzden çoğu küçük işletmeye Wix’i öneriyorum. Sitelerin hepsi birbirine mi benziyor? Evet; bu mutlaka kötü bir şey de değil. Kullanması ve güncellemesi kolay olduğu için müşteriler ihtiyaç duydukları güncel bilgiyi alabilmekten memnun oluyor.
    Görmek istediğim şey “Wix Widgets” gibi bir şey. REST servis çağrılarını bağlayan ve veri noktalarını widget gösterimiyle eşleyen düzeyde özelleştirme sunan, veriye bağlı widget’lar. Günümüzde her şirkette bulunan şirket içi web sitesi ihtiyaçlarını karşılamakta epey işe yarardı.
    Web sayfalarının %90–95’i gerçekten basit bir çözüme ihtiyaç duyuyor.
  • Web platformunun en iyi ve en tutarlı çapraz platform GUI sistemi olduğunu duyup dururken, o sistemin üzerinde bir şeyler geliştirmenin berbat olması komik.
    Belki de bunun GUI’nin doğası olup olmadığını merak ediyorum. Her talimatı tek tek vermek gerekiyor, çok sayıda çevrim tüketiyor ve aksi hâlde çapraz platform çalışmayan bir yapı olabilir.
  • Bu sorunun bir kısmı, HTML dosyasındaki etiket ve öğelerin sürekli artmasından kaynaklanıyor. Belge işaretlemesi olmaktan çıkıp sayfa işaretlemesine dönüştü; birinin nerede bitip diğerinin nerede başladığını ayırt etmek zor. W3C article ve section öğelerini ekleyerek bunu denemiş olsa da.
    Elbette ham HTML kodu zaten geliştiriciler dışında birinin okuması için tasarlanmamış olabilir; o tarafı da var.

• Saf HTML modal geldiğini duyunca gerçekten heyecanlanmıştım, ama JavaScript olmadan tetiklemenin bir yolu olmadığını öğrenince hayal kırıklığına uğradım. Saf HTML ile yalnızca kapatılabiliyor, açılamıyor.
  https://github.com/whatwg/html/issues/3567
  dialog öğesi harika bir ekleme ve uygulanıyor olmasına seviniyorum; ancak temel işlevlerin bir kısmı JavaScript’e bağlı. dialog açmak için JavaScript ile open özniteliğini ayarlamak gerekiyor.
  button ya da a öğesinin bir iletişim kutusunu açabilmesinin bir yolu olsa iyi olurdu. HTML’de yerleşik sayfa etkileşimi için zaten emsaller var. Örneğin bağlantılar sayfayı kaydırabiliyor, details öğesi bir etkileşimden sonra öğeleri gizleyebiliyor; dolayısıyla başka bir sayfa öğesinin dialog açabilmesi de doğal görünürdü.

  • “Yalnızca HTML” gibi yüce bir amaç, HTML’e betik yazma özellikleri eklemek gerektiği anlamına geliyorsa emin değilim. Öyle bir durumda bence doğrudan JavaScript kullanmak daha iyi.
  • JavaScript olmadan, yalnızca HTML ve CSS ile de modal uygulanabilir.
    Örneğin burada sağ üstteki ? işaretine tıklayabilirsiniz: https://aavi.xyz/proj/colors/
  • HTML’in kendisine yerleşik olsa güzel olurdu; ama en azından gereken JavaScript karmaşık değil ve onclick özniteliğine de konabilir.
  • Geçerli hash’e göre gösterilip gizlenmesi sağlanabilir. Elbette bu yöntem CSS gerektiriyor.