HTML Table için de bir API olduğunu biliyor muydunuz?

• HTMLTableElement API, uzun zamandır var olan ancak neredeyse hiç kullanılmayan, HTML tablolarını yönetmeye yönelik yerleşik bir arayüzdür
• Bu API ile tbody, thead, tfoot, caption, row, cell gibi öğeler doğrudan oluşturulup erişilebilir; değişiklik yapıldığında tüm tabloyu yeniden render etmek gerekmez
• Örnek kodda iç içe dizilerden tablo üretme ve insertRow() ile insertCell() kullanarak satır ve hücre ekleme yöntemi gösteriliyor
• t.rows[1].cells[1] gibi ifadelerle hücrelere indeksle erişmek veya insertRow(-1) ile sona satır eklemek gibi çeşitli işlemler mümkün
• Yazar, bu API’nin bir veri yapısı olarak tablonun işlevlerini genişletme potansiyeline sahip olduğunu, form gibi olaylar veya ek yeteneklerle geliştirilebileceğini belirtiyor

---

HTML tablo API’sine genel bakış

• Geliştiricilerin çoğu tabloları DOM metotlarıyla (createElement vb.) ya da innerHTML ile metin ekleyerek oluşturuyor; ancak ikinci yöntem güvenlik riski taşıyor
• HTML’de eski bir HTMLTableElement API bulunuyor ve bununla tablonun gövdesi, satırları, hücreleri, başlığı, alt bilgisi, caption ve summary gibi bölümleri yönetilebiliyor
• Bu API sayesinde tablonun tamamını yeniden render etmeden tek tek öğeler üzerinde işlem yapılabiliyor

Kod örneği: diziden tablo oluşturma

• Örnekte aşağıdaki gibi bir iç içe dizi tabloya dönüştürülüyor
  • [['one','two','three'], ['four','five','six']]
• document.createElement('table') ile tablo oluşturuluyor, ardından her satır (insertRow) ve hücre (insertCell) döngü içinde ekleniyor
• Her hücrenin içeriği innerText ile ayarlanıyor

Hücreye erişim ve düzenleme

• Oluşturulan tablodaki hücrelere indeks tabanlı erişim mümkün
  • Örnek: t.rows[1].cells[1] → <td>five</td>
• Satırlar ve hücreler silinebilir veya yenileri eklenebilir
  • Örnek: t.insertRow(-1) ile sona satır ekleme
  • t.rows[2].insertCell(0) ile yeni hücre oluşturup ardından innerText = 'foo' ile değer atama

API’nin sınırlamaları

• insertRow(-1) gibi sezgisel olmayan indeks kuralları bulunuyor
• TH öğesini doğrudan oluşturmanın bir yolu yok, tüm hücreler TD olarak ele alınıyor

Gelecekte genişletme potansiyeli

• Yazar, tablo oluşturmanın pratikte zahmetli olduğunu vurgulayarak bu API’nin yeniden değerlendirilip işlevlerinin genişletilmesi gerektiğini öne sürüyor
• HTML formlarına formData ya da change event eklendiği gibi, tablolara da event’ler veya gelişmiş özellikler kazandırılabileceğini belirtiyor
• Böylece tablolar yalnızca bir yerleşim aracı değil, bir veri yapısı olarak da konum kazanabilir

[sonnet]

Nispeten az deneyimli bir geliştirici olarak, en başından beri kullanılan bir API'den sanki onu "keşfetmiş" gibi söz eden yazılar beni şaşırtıyor.

[GN⁺]

Hacker News yorumları

• Görünüşe göre birçok kişi makaleyi doğru düzgün okumamış. Bu yazının özü `` etiketinin kendisi değil, table’a özel DOM arayüzleri. Örneğin HTMLTableElement.prototype.insertRow() veya HTMLTableRowElement.prototype.insertCell() gibi metodlar, createElement() ya da appendChild() kullanımından daha sezgisel. Ancak React, Svelte, Vue gibi kütüphane tabanlı UI dünyasında bu tür metodlar artık neredeyse hiç kullanılmıyor. HTML sözdiziminde olduğu gibi thead, tbody, tfoot atlandığında bunun otomatik ele alınması ilginç. Son 5 yılda demo script’lerinde .insertRow, .insertCell, .createTHead, .rows, .cells öğelerini doğrudan kullandığım oldu. Kod stili açısından forEach yerine for kullanmanın ve indeks parametresini atlamanın daha temiz olduğunu düşünüyorum.

  • Bugün framework’ler temel DOM manipülasyonunun çok fazlasını ikame ettiğinden, bu tür temel bilgileri bilen kişi sayısı azalmış gibi geliyor. `` etiketinin ilk eklendiğine dair C|net haberini okuduğum zamanları hatırladım. Sanırım ben de epey yaşlanmışım.

• Yaklaşık altı ay önce MDN belgelerine bakarken ya da AI tavsiyesiyle bu API’yi kullandığımı hatırlıyorum. rows ve cells özellikleri, klavye gezinmesi uygularken çok kullanışlıydı. Bununla ilgili bir örnek ClickHouse kodunda görülebilir.

  • Bugünün web’inde beni en çok üzen şey, div ile tablo yapan insanlar. Sıralama da düzgün çalışmıyor; özellikle M365 Admin gibi yerlerde tablo uygulamalarının berbat örnekleri çok.

• Bu, butonlarla ilgili tartışmayla (önceki başlık) benzer bir bağlamda. Yaklaşık 10~15 yıl önce her şey `` olmaya başladı ve HTML, semantik işaretleme yerine bir UI araç kutusu gibi kullanılmaya başlandı.

  • Bunun nedeni DOM’un baştan beri semantik belge değil, bir render hedefi olarak kullanılması. Semantik HTML iyi bir fikir ama pratikte bunu beklemek zor. Üstelik semantik öğelerin varsayılan stilleri olduğundan, geliştiriciler daha nötr olan etiketini tercih ediyor. Aslında ve `` ayrımının yapılmış olmasını da bir tasarım hatası olarak görüyorum.
  • 20 yılı aşkın süredir HTML kullanıyorum ama benim deneyimime göre çoğu kişi hâlâ anlamlı etiketleri epey iyi kullanıyor. Elbette her şeyi div ile yapanlar var ama örneğin butonlar genelde doğru yazılıyor.
  • Bence bu değişim kaçınılmazdı. Web içeriğinin büyük kısmı pazarlama odaklı, dolayısıyla şirketler tam istedikleri biçimde görünmek istiyor. Teknik belgeler için ayrı bir DocBook web’i olsa, kullanıcıların kendi stillerini uygulayabilmesi ilginç olurdu.

• Stable Diffusion görsel karşılaştırma aracı yaparken bu API’yi kullanmıştım. Çok sayıda satır ve sütun olduğu için tabloyu sık sık yeniden oluşturmak gerekiyordu; ancak tek seferde string üretme yaklaşımına kıyasla DOM güncellemeleri daha yavaş kaldı. Sanırım bunun nedeni her API çağrısının DOM’u anında güncellemesi.

• “Tüm tabloyu yeniden render etmeye gerek yok” deniyordu ama aslında standart DOM metodları da zaten böyle çalışıyor. Yine de sıkıcı DOM dolaşımını azaltabilmesi oldukça hoş.

  • WebKit koduna baktığımda içeride aynı mantığın çalıştığını gördüm; yani performans farkı neredeyse yok.

• HTML form API’sini de yeniden keşfetmek gerekiyor.

• Tabloların sorunu veri doldurmak değil, arama·sıralama·filtreleme özelliklerinin hiç olmaması.

  • Bunu neyle kıyaslayarak söylediklerini merak ediyorum. Tablolarda da bu özelliklerin uygulanamaması için bir neden görmüyorum.

• “Bu API terk edilmiş” denmesini anlamıyorum. Ben hâlâ HTML tabloları oluştururken bunu sık kullanıyorum.

  • “Abandonware” ifadesi aslında lisans bağlamında kullanılan bir terim; burada biraz abartılı bir başlık olmuş. Yazar galiba bunun, genişleme alanı olan eski bir alan olduğunu söylemek istiyordu. Form API’sinde olduğu gibi tablolara da sıralama·filtreleme gibi özellikler eklenebilir.
  • Günümüzde çoğu kişi React veya Svelte gibi deklaratif UI framework’leri kullandığından, bu tür imperative DOM API’leri giderek niş bir alana dönüşüyor.
  • Kısacası artık React çağı.

• Örnek kod ilginç ama değişken adları fazla kısaltıldığı için okunabilirlik düşüyor. b, t, r, c yerine anlamlı adlar kullanmak daha iyi.

  • Bu tür tartışmalar sonuçta biraz bisiklet kulübesi tartışması gibi, önemsiz ayrıntılara odaklanıyor hissi veriyor.
  • Kısa scope içinde kısa değişken adları kullanmak doğal.
  • Yine de tek harfli değişken adlarının yanlış bir optimizasyon olduğunu düşünüyorum. Haskell kullanan biri olarak buna özellikle katılıyorum.
  • Kısa adlardan çok (ri, i) gibi karışık indeks kullanımı daha kafa karıştırıcı. Benzer role sahip değişkenlerde uzunluğu da tutarlı yapmak iyi olur.
  • Özellikle let b = document.body; gibi satırları okumak zor. Birkaç byte tasarruf edeceğim diye sadece bilişsel yük artıyor.