Geçen ay, İstanbul’da bir editoryal not hazırlarken yine aynı döngüye girdim: © müydü, ©right; müydü, yoksa decimal karşılığı mı vardı? Açık konuşayım, bu iş bazen sinir bozucu oluyor — itiraf edeyim, beklentimin üstündeydi —. Bir sembolü yazmak istiyorsunuz ama hafızanız size minik bir oyun oynuyor… ve birkaç dakika gidiyor. Sadece birkaç dakika, evet — ama günde on kez olunca bu iş ayrı bir his.
İşte tam o anda insanın aklına şu geliyor: “Bunu niye daha kolay hale getirmiyoruz?” Sen de böyle düşünüyorsan yalnız değilsin. Ben de 2024’ün sonlarında kendi küçük demo projelerimde benzer bir şeyle boğuşurken tek tek entity aramak yerine karakteri yazıp geçmek istiyordum — yani iki sekme arasında gidip gelmek, Stack Overflow’da aynı soruyu tekrar açmak, bunlardan bıkmıştım açıkçası. Sonuç? Basit ama bayağı iş gören bir reference ekranı fikri çıktı ortaya.
Neden Böyle Bir Araç Gerekli?
İtiraf edeyim, Lafı gevelemeden söyleyeyim: HTML entity işi küçük görünür. Ama üretkenliği kemiren detaylardan biridir, özellikle teknik blog yazıyorsan, dokümantasyon hazırlıyorsan ya da Markdown içinde HTML anlatıyorsan sürekli kaçış dizileriyle uğraşırsın. “Ben zaten karakteri göstereceğim” dersin; sistem sana tag diye davranır. Can sıkıcı.
Bunu geçen sene Kadıköy’de bir kahve molasında arkadaşım Efe ile konuşurken fark ettim. Adam kurumsal içerik ekibinde çalışıyor. Her gün üç ayrı formatta aynı sembole bakmak zorunda kalıyordu — sabah named, öğleden sonra decimal, akşam hex, neredeyse rutine girmişti. Bir noktadan sonra mesele bilgi değil, sürtünme oluyor. Kullanıcı ne istediğini biliyor ama araç onu yavaşlatıyor. Hmm, tanıdık his değil mi?
Bu yüzden iyi bir lookup aracı sadece “arama” yapmamalı; kullanıcıya doğru yolu da göstermeli. İsimden bulsun, karakterden bulsun, sayıdan bulsun… hatta açıklamadan bile bulsun. İnsanlar bazen “copyright” diye yazar, bazen direkt © koyar, bazen de 169’un peşine düşer (yanlış duymadınız). Araç hepsini anlamalı.
Küçük ekip için başka, kurumsal ekip için başka
Küçük bir startup’ta bunu kurduğunda asıl kazanç hız olur. Kimse uzun eğitim istemez; açarsın, ararsın, kopyalarsın ve geçersin. Enterprise seviyede ise hikâye biraz değişiyor — burada tutarlılık ve doğruluk daha kilit hale geliyor, mesela içerik ekibiyle frontend ekibi aynı referansı kullanmalı ki biri named formla giderken diğeri hex yüzünden saç baş yolmasın. Siz hiç denediniz mi? İki farklı çıktı, iki farklı ekip, bir sürü gereksiz tartışma.
Neyse uzatmayalım… İyi araç dediğin şey aslında görünmez olur. Kullanıcı onun varlığını düşünmez bile çünkü işini hallediyordur.
Tasarımdaki En Güzel Hile: Klavyeyi Öncelemek
Tuhaf ama, Bu tür mini araçlarda mouse’a güvenmek çoğu zaman gereksiz yük bindiriyor. O yüzden autofocus fikri çok mantıklı; sayfa açılır açılmaz imleç search kutusuna düşüyor. Kullanıcı hemen yazmaya başlıyor. Bu detay küçük gibi duruyor ama benzer akışı kendi denediğim mini reference uygulamasında test ettiğimde fark barizdi: ilk etkileşim süresi ciddi biçimde kısaldı. Gerçekten.
Bir de şu var: arama alanına odaklanma alışkanlığı özellikle yoğun çalışan geliştiricilerde işe yarıyor çünkü el klavyedeyken beyin de orada kalıyor (evet, kulağa basit geliyor ama öyle). “Sayfayı geziyorum” hissi yerine “sorumu sorup cevabı alıyorum” hissi veriyor bu yapı — ve bu fark küçümsenecek bir şey değil bana sorarsanız.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Kullanıcı Neden Gitmeden Önce Beklemez? Hızın Gizli Bedeli yazımızda bu konuya da değinmiştik.
İyi bir entity reference aracı uzun liste sunmaz; doğru sonucu hızlı verir. Fazla seçenek çoğu zaman fayda değil gürültüdür.
Editör masasında bu haberi ilk okuduğumda şunu düşündüm: aslında sorun entity sayısı değil… sorun hatırlama yüküydü. Named mi decimal mı hex mi derken kafa dağılıyor ve asıl işten kopuyorsun. Tam da böyle.
Arama mantığı neden önemli?
Araç beş farklı alan üzerinden arama yapınca — isim, karakter, kod noktası, kategori ve açıklama — kullanıcı nereden gelirse gelsin sonuç bulabiliyor. Mesela biri “math” yazarak sembol grubuna ulaşır; biri doğrudan 8800 gibi kod numarası girer; biri de çarpma işaretini görüp adını bilmeden arar. Hepsi farklı yol, hepsi aynı hedefe varıyor.
Bir dakika — bununla bitmedi.
{
"name": "copy",
"char": "©",
"code": 169,
"category": "punct",
"desc": {
"ja": "",
"en": "copyright"
}
}Bana göre burada en hoş ayrıntı strict match yaklaşımı. Tek karakterli aramada includes kullanırsan işler karışır; mesela & her yerde çıkmaya başlar. “and” geçen her metne bulaşırdı bu sefer… Küçük bug gibi görünür ama kullanıcı deneyimini bozar. E peki, sonuç ne oldu? Sinsice. Daha fazla bilgi için Honda Super-N Avrupa’ya Geliyor: Retro Mini, Büyük Merak yazımıza bakabilirsiniz.
Neden Tüm HTML5 Entity’leri Değil de Sadece Seçilmiş Olanlar?
Burası bence projenin en sağlam tarafı — ama biraz da hayal kırıklığı yaratabilecek kısmı diyebilirim, çünkü insan ilk bakışta “2200+ entity varken neden sadece altmış tane?” diye soruyor. Cevap makul geliyor sonra ama ilk tepki genelde o soru oluyor.
Düzgün seçilmiş altmış kayıt binlerce kayıttan daha değerli olur mu? Bence olur. Browsable kalır — yani scroll cenneti değil, scroll cezası olmazsınız. Rate Limiting Deep Dive: Token Bucket, Leaky Bucket ve Sliding Window yazımızda bu konuya da değinmiştik.
Curation over completeness
Bir şey dikkatimi çekti: Ben buna yıllardır inanıyorum, özellikle reference araçlarında. Kendi not defterlerimde de hep aynısını yaptım; her şeyi doldurmak yerine gerçekten kullanılan örnekleri öne çıkardım. Ha bu arada benzer yaklaşımı HTTP status kodlarıyla ilgili eski notlarımda da görmüştüm — fazlalık gösteriştir. Kullanılabilirlik değildir. Neyse, konuya dönelim.
| Kriter | Tam Liste | Seçilmiş Liste |
|---|---|---|
| Kullanılabilirlik | Düşük-orta | Yüksek |
| Tarama hızı | Zayıf olabilir | Bayağı iyi olur |
| Eğitim ihtiyacı | Daha fazla ister | Neredeyse yoktur |
| Sürdürülebilirlik testleri | Zorlaşır | Daha rahat yapılır |
Kopyalama Deneyimi Neden Bu Kadar Önemli?
Ara yüzde üç ayrı buton koymak ilk bakışta fazla gelebilir. Ama pratikte mantıklı duruyor — named, decimal, hex formunu tek tıkla almak güzel bir konfor veriyor. Hele bir de dokümantasyon veya CMS içinde çalışırken bazen sadece belirli formu yapıştırman gerekiyor, dön dolaş tekrar dönüş yapmak istemiyorsun. Bu özellik fena değil, hatta baya işe yarıyor.
Name, Decimal, Hex: Hangisini Ne Zaman Kullanırsın?
- Name: Okunabilirlik istiyorsan en rahat seçenek. Blog yazısında veya öğretici içerikte temiz durur. — bunu es geçmeyin
- Decimal: XML kökenli sistemlerde veya sayı tabanlı referanslarda kullanışlıdır.
- Hex: Unicode tablosuyla eşleşirken kafanı rahatlatır; teknik belgelerde yer yer daha düzenlidir. — ciddi fark yaratıyor
Kendi deneyimimden söyleyeyim: Ankara’da müşteriye hazırladığım statik site dokümantasyonunda named form bana çok vakit kazandırmıştı (yanlış duymadınız). Çünkü içerik editörü sembolün ne olduğunu biliyordu ama nasıl yazıldığını bilmiyordu; adı görünce “tamam” demesi yetti. Bir kere o bariyer kalkınca akış hızlanıyor — bunu yaşayarak anlıyorsunuz zaten.
Mimaride Hafiflik Neden Kazandırıyor?
No build, no dependency, no drama… Bunlar kulağa slogan gibi geliyor olabilir ama aslında bakım maliyetinin özü bunlarda saklı. Eğer proje sırf ufak bir reference ekranı için devasa paketlere girerse olay büyür; tarayıcıda gecikme artar, deploy süreci ağırlaşır, sonra kimse ellemek istemez. Aynısını Haziran ayında kendi yan projemde yaşadım — gereksiz bağımlılık yüzünden başlangıç süresi uzayınca ben bile sıkıldım. Kendi projem, dikkat edin.
Sade yapı özellikle iki senaryoda parlıyor: bireysel kullanımda hızlı açılıyor, ekip içi kullanımda da kırılganlık azalıyor. Tabii kağıt üstünde süper olan bazı sade mimariler pratikte sınıfta kalabiliyor; burada güzel olan şey şu ki veri seti küçük olduğu için risk yönetilebilir kalıyor. Dur, şöyle anlatayım: — ki bu tartışılır — az parça = az hata alanı. Bu kadar. HTTP Durum Kodları: 36 Kodu Tek Ekranda Topladım yazımızda da bu konuya değinmiştik. Crimson Desert’te Intel Desteği: Arc Sahneye Çıkıyor yazımızda da bu konuya değinmiştik.
Peki eksisi ne?
Şöyle ki, Eksi tarafını da söyleyelim: çok kapsamlı araştırma yapan biri bütün dünya entity’lerini bekleyebilir. Bu listede bulamayınca hafif burun kıvırabilir. Haklı mı? Bir yere kadar evet. Ama hedef kitlen geliştirici günlük işleri ise tam liste çoğu zaman gereksiz şişkinlik yaratıyor (en azından benim deneyimim böyle). Geniş kapsam isteyenler resmi WHATWG listesinden ilerler, kısa yol isteyenler ise bu tarz küratörlü çözümleri sever.
Bende Uyandırdığı Asıl Düşünce Ne?
Editör olarak böyle projelere baktığımda hep aynı yere geliyorum: iyi ürünlerin ortak noktası parlak fikir değil, sürtünmeyi azaltmalarıdır. İnsan bazen yeni teknoloji bekliyor; oysa günlük hayatta en çok kazandıran şey sıradan görünen minik kolaylıklardır. Geçen Şubat ayında İzmir’de yaptığım kısa atölyede bunu öğrendim — katılımcılar en basit shortcut özelliğine bile şaşırmıştı. İnsan gerçekten akışı seviyor.
Araya gireyim: Aynısını lookup araçlarında da görüyoruz: doğru anda doğru bilgi önüne düşerse geri kalan detaylar pek önem taşımıyor. Belki görkemli değil, belki trend listelerine girmeyecek… Ama gün sonunda iş görüyor mu? İşte mesele orası. Biraz idare eder gibi duran çözümler bazen en sağlam çözümler oluyor.
Sıkça Sorulan Sorular
“
“HTML entity nedir ?” “
”
“HTML entity, özel karakterleri güvenle göstermek için kullanılan kaçış biçimidir. Örneğin © karakterini doğrudan ya da © şeklinde yazabilirsin. Tarayıcı bunu doğru şekilde yorumlar.”
“Named mi decimal mi hex mi tercih edilmeli ?” “
”
“Okunabilirlik gerekiyorsa named form genelde en rahatıtır. Teknik referanslarda decimal ya da hex kullanmak daha uygun olabilir. Hangi ortamdaysa ona göre seçim yapmak en temiz yoldur.”
“Neden tüm HTML5 entity’leri eklenmemiş ?” “
”
“Çünkü tam liste pratikte aşırı kalabalık oluşturuyor ។ Kürate edilmiş kısa liste hem hızlı taranıyor hem de gerçek kullanım senaryolarına odaklanıyor. Her şeyi koymak her zaman daha iyi olmuyor.”
“Kaynaklar İleri Okuma”
”
”
WHATWG Named Characters Listesi
”
“
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
