`<dl>` Hakkında (2021)

 (benmyers.dev)
1 puan yazan GN⁺ 9 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • ``, ad–değer çiftleri listesini anlamsal olarak ifade eden bir HTML öğesidir; konaklama olanakları, fatura kalemleri ve teknik terimler sözlüğü gibi UI desenleri için uygundur
  • Açıklama listesi, adını** ve ** değerini dl içine yerleştiren bir yapıdır; tek bir ada birden fazla değer de bağlanabilir
  • Stil vermek için ilişkili ve öğelerini gruplamak gerektiğinde, spesifikasyona göre yalnızca `` sarmalayıcısı grubu çevreleyebilir
  • Yalnızca iç içe geçmiş div kullanıldığında yardımcı teknolojilerin liste desenini tanıması zorlaşır; buna karşılık dl, öğe sayısı, mevcut konum ve listeyi atlama gibi gezinme avantajları sunar
  • Dungeons & Dragons stat bloklarında olduğu gibi farklı türde sayısal, yetenek ve eylem verileri de açıklama listelerine ayrılabilir; bu da ne kadar genel amaçlı olduğunu gösterir

`` öğesinin ifade ettiği desen

  • ``, ad–değer çiftleri listesini ifade eden bir HTML öğesidir ve web arayüzlerinde tekrar tekrar görülen bu desene anlamsal bir anlam kazandırır
  • Konaklama tesislerinin olanakları, aylık kiranın ayrı fatura kalemleri ya da teknik terimler sözlüğü gibi, ad ve değerin eşleştiği yapılar bunun tipik adaylarıdır
  • tek başına bir öğe değildir;, , olmak üzere üç öğenin birleşimiyle ad–değer grupları kurulur
  • HTML5’ten önce ``, definition list olarak adlandırılırdı ve aslen terim ve tanımlardan oluşan bir sözlüğü ifade etmek için tasarlanmıştı

Açıklama listesinin temel yapısı

  • , , ``

    • `` tüm açıklama listesini sarar; bu yönüyle ul ya da ol öğesinin tüm listeyi sarmasına benzer
    • ** description term olarak adı gösterir, ** ise description detail olarak değeri gösterir
    • ve da daha önce sırasıyla definition term ve definition detail olarak biliniyordu
    • Temel yapı, bir dt öğesinin ardından bir dd öğesi gelmesidir

	Title
	Designing with Web Standards

  • Birden fazla ad–değer çifti

    • Aynı listeye başka ad–değer çiftleri eklemek için yeni dt ve dd öğeleri art arda yerleştirilir

	Title
	Designing with Web Standards
	Publisher
	New Riders Pub; 3rd edition (October 19, 2009)

  • Tek bir ad için birden fazla değer

    • Bir dt öğesinin birden çok `` değeri olabilir
    • Kitabın birden fazla yazarı olması gibi durumlarda, tek bir ada birden fazla değer bağlanan yapı doğrudan ifade edilebilir

	Title
	Designing with Web Standards
	Author
	Jeffrey Zeldman
	Ethan Marcotte
	Publisher
	New Riders Pub; 3rd edition (October 19, 2009)

  • Stil vermek için sarmalayıcı

    • İlgili dt ve dd öğelerini stil amaçlı gruplamak gerektiğinde `` sarmalayıcısı kullanılabilir
    • Spesifikasyona göre dt/dd gruplarını sarabilen tek sarmalayıcı öğe ``’dir
    • İzin verilen yapı ve kısıtlar hakkında daha fazla bilgi için MDN’deki `` belgesine veya HTML spesifikasyonuna bakılabilir

		Title
		Designing with Web Standards

		Author
		Jeffrey Zeldman
		Ethan Marcotte

Anlambilimin neden gerekli olduğu

  • Ad–değer grupları yalnızca iç içe geçmiş div yapılarıyla da görsel olarak oluşturulabilir, ancak tarayıcıların ve yardımcı teknolojilerin bunu bir liste deseni olarak tanıması zordur
  • Anlamsal öğe seçimi, bilgisayar bu deseni tanıdığında kullanıcıya gerçekten bir fayda sağlayıp sağlamadığına göre değerlendirilebilir
  • `` kullanıldığında ekran okuyucu kullanıcıları ad–değer grupları listesini daha kolay gezebilir
    • Listedeki ad–değer grubu sayısını öğrenebilirler
    • O anda listede hangi konumda olduklarını anlayabilirler
    • İlgilenmiyorlarsa tüm listeyi tek bir blok gibi atlayabilirler
  • İç içe div yapısında her ad ve değer bağımsız bir metin düğümü gibi ele alınırken, `` aynı bilgiye yapısal anlam kazandırır
  • Bu avantajlar, çoğu tarayıcı/ekran okuyucu birleşiminde `` kullanıldığında pratikte de sağlanır
  • Ancak desteği henüz her yerde yaygın olmadığından, bağımsız metin düğümleri olarak işlenen geri dönüş deneyimi yeterli değilse destek iyileşene kadar gibi başka öğeler de tercih edilebilir

Dungeons & Dragons stat bloğu örneği

  • Dungeons & Dragons stat bloğu, çok sayıda ad–değer çifti içeren iyi bir örnektir ve tek bir stat bloğu içinde birden fazla açıklama listesi adayı bulunabilir
  • Armor Class, Hit Points, Speed gibi temel sayılar; STR ve DEX gibi yetenek puanları; Senses, Languages, Challenge gibi ustalık bilgileri; ayrıca Traits ve Actions ayrı açıklama listelerine bölünebilir
  • Görsel olarak farklı duran yetenek listeleri ve saldırı listeleri de aslında açıklama listesi deseni ile ifade edilebilir
  • Birden fazla açıklama listesini ayırt etmek veya bunları başlıklarla ilişkilendirmek için aria-label ve aria-labelledby kullanılabilir
  • Bu işaretleme mümkün yollardan yalnızca biridir; farklı biçimlerdeki veri kümelerine de uygulanabilecek kadar genel amaçlı olduğunu gösteren şey, tam da bu `` desenidir

İlgili okumalar

2 yorum

 
GN⁺ 6 시간 전
Lobste.rs görüşleri
  • Markdown'da açıklama listesi (description list) olmaması üzücü
    • Pandoc tarzı Markdown, en az iki sözdizimiyle açıklama listelerini destekliyor
      Ancak çoğu uygulamanın bunu desteklemediği doğru. Buna karşılık dizgi sistemi/işaretleme dili Typst, / term: description gibi birinci sınıf bir sözdizimiyle açıklama listeleri sunuyor; bence bu da - madde işaretli listeler ve + otomatik numaralı listelerle iyi uyum sağlıyor
    • Hugo, Pandoc ve GFM gibi bazı uygulamaların şu biçimi desteklediğini hatırlıyorum 
      dt  
: dd  

dt  
: dd
    • Markdown, HTML'de olan her şeye sahip olabilir. Çünkü HTML'nin üst kümesidir
    • https://www.djot.net/ açıklama listelerini destekliyor. Daha da önemlisi, Djot HTML'nin üst kümesi değil; bu sayede şişkin HTML destekli tarayıcıların dışında da kullanılabiliyor
  • Kişisel olarak tüm zamanların ilk beş öğesi arasında yer alıyor
    • <details> ile birlikte kesinlikle üst sıralarda. Böyle etkileşimli öğelerin daha fazla olmasını isterdim
  • Tek bir öğede birden fazla <dt> de bulunabilir. Sözlük tarzı listelerde eş anlamlılar gibi şeyleri ifade etmek için kullanılabilir
    CSS ile stillendirirken bitişik kardeş seçiciye alışmakta fayda var
    Not: https://developer.mozilla.org/en-US/docs/…
 
GN⁺ 9 시간 전
Hacker News yorumları

  • Bu yanlış: için karşılık gelen örtük bir rol yok ama `group`, `list`, `none`, `presentation` rolleri verilebilir `aria-label` yalnızca örtük ya da açık, uyumlu bir rolü olan öğelerde tanımlanabilir ve `aria-label` çoğu rolde izinlidir, ancak burada `presentation` ve `none` dışarıda kalınca geriye sadece `group` ve `list` kalır `group` tuhaf, `list` ise kabul edilebilir; dolayısıyla sonuç **ya `aria-label`i kaldırmak** ya da `role="list"` eklemek olmalı. O zaman çocuklarda `role="listitem"` de gerekir Yazının gözden kaçırdığı nokta, tek bir değil, art arda birden fazla `` gelebilmesidir. Spesifikasyondaki örnek iyi: https://html.spec.whatwg.org/multipage/grouping-content.html... Bu bir ad-değer çifti değil, bir ad-değer grubu

    • Bunu hiç bilmiyordum. Merak ettim, ve saran öğesine `role="listitem"` mı verirdiniz? `role="listitem"` üzerinde izinli görünüyor ama birkaç birlikte gruplanınca tam doğru görünmüyor vein asıl terim olarak yorumlanma biçimini de bozup bozmayacağından emin değilim
    • Eski HTML5 Doctor yazısı hâlâ en sevdiğim: https://html5doctor.com/element-index/

  • Burada popüler olmayabilir ama semantik HTML kullanmaya uğraşmadığımdan beri hayatım daha kolay. Tasarım pek iyi değil Ne zaman kullanmaya çalışsam sonunda pişman oldum. Çünkü birden çok katman sarmalayıcı gerekiyor ya da bölümler arasında ayırıcı çizgiler, ikonlar veya birden fazla anahtar-değer çiftine yayılan başlıklar gerekiyor Bir miktar esnekliği var ama iddia ettiği genelleştirilmiş kavramı pratikte taşımaya çok uzak. Elbette, `` gibi gözle görülür faydası olan karşılık gelen öğeleri hâlâ kullanıyorum ama veri modeline tam oturmuyorsa ve her şeyi ezmeniz gerekiyorsa bu pratik bir seçim değil Kullanımın %99'u API'yi dolanıyorsa bunun muhtemelen API'nin suçu olduğunu söylemek o kadar da tartışmalı olmamalı

    • Her gün ekran okuyucu kullanan biri olarak kesinlikle katılıyorum W3C ideolojik semantik saflık saçmalığını bırakıp daha gerçekçi bir yaklaşım benimsese herkes için daha iyi olurdu. Bakmaları gereken şey, API'nin semantik olarak ne kadar saf olduğu değil; geliştiricilerin ne yapmak istediği, karşı çıksanız bile hangi hilelere başvuracakları ve bunun herkes için en faydalı şekilde nasıl mümkün kılınacağıdır ARIA live region bunun kusursuz bir örneği. Geliştiricilerin aslında istediği şey document.speakText. Ellerinde olan şey ise, sayfadaki metin değiştiğinde bunun okunmasını sağlayan tuhaf bir API. Bu ikisi arasında köprü kurmak gerekiyor ve iyi uygulanmış hâli bile zor, hack'e yakın. Ama en azından live region yöntemi semantik olarak saf HTML sayılıyor herhalde
    • Bu daha çok CSS'nin suçu gibi geliyor. display:contents ile sarmalayıcıyı kaldırmayı mümkün kıldığı gibi, öğeleri ortak bir üst ataları varmış gibi gruplayacak bir yol da eklenmeli bence :wrap(dt, dt+dd) {border: solid 1px}
    • HTTP için de benzer hissediyorum. Bu protokol S3 gibi kaynak depoları için gerçekten çok uygun. GET, PUT, DELETE gayet anlamlı ve HTTP durum kodları da tam bu kullanım için tasarlanmış Ama web geliştiricisi olarak çoğumuz kaynak deposu yapmıyoruz. Bunlar çok genel amaçlı şeyler; bir kez yapılır, milyonlarca uygulama kullanır. Biri HTTP ile etkileşen kod yazdığında çoğu zaman aslında uzak prosedür çağrısı yapıyor GraphQL, gRPC ya da başka bir uzak prosedür çağrısı sistemi kullanınca bunu toptan atlatıyorsunuz. Her şeyi tek bir endpoint'e POST ediyorsunuz ve bir soyutlama katmanı daha ekleyerek uygulamaya çok özgü durumların her biri için 4XX/5XX hataları döndürmek zorunda kalmıyorsunuz RFC yazarlarının biraz ileri gittiği açık. 402 Payment Required, 407 Proxy Authentication Required, 508 Loop Detected gibi şeyler, belirli uygulama ya da dağıtım türlerine özgü özellikleri web'in temeline sıkıştırma girişimi gibi görünüyor Neden RFC yazarlarının özel ihtiyaçları web'in temelinde uygulanıyor da benim ihtiyaçlarım için denk gelen bir şey arayıp uygulamaya özgü her şeyi 400 Bad Request ya da 500 Internal Server Error içine sıkıştırmak zorunda kalıyorum, bilmiyorum. Web uygulamalarının HTTP durum kodlarını asgari düzeyin ötesinde gerçekten kullandığını her gördüğümde göz deviresim geliyor. Bunlar uygulama katmanında olmalı. Bu protokol sizin için değil, çoğunlukla statik içerik sunan LAMP stack uygulamaları için yapıldı

  • Bu biraz liste tarihi dersi. Aşağıdaki 1985 tarihli IBM mainframe DCF/GML kılavuzuna bakarsanız, DL-DT-DD web'den önce de vardı 40 yılı aşkın bu belgede yalnızca Definition lists (DL) değil, Glossary lists (GL), Ordered lists (OL), Unordered lists (UL), Simple lists (SL) de var ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementation Guide Rel 3 Mar85 https://archive.org/details/bitsavers_ibm370DCFSpositionFaci...

    • GML 1969'a, SGML ise 1970'lere kadar gidiyor. İçeride BookMaster diye bir şey kullanıyorlardı; HTML'nin selefi gibi görünüyordu `` yerine :p., `

  • yerine:li.` kullanılıyordu. 1990-1991 civarında TBL HTML ve HTTP'yi geliştirirken, hiperortama odaklı bir SGML uygulaması olan HyTime diye bir girişim de vardı. HTML onu oldukça hızlı biçimde geride bıraktı GML/SGML'nin arkasındaki Charles Goldfarb için https://en.wikipedia.org/wiki/Charles_Goldfarb, SGML için de https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La... bakılabilir

    • IBM'in Generalized Markup Language'i, SGML'ye (Standard Generalized Markup Language) dönüştü ve Tim Berners-Lee HTML üzerinde çalışırken CERN'de SGML'nin yoğun kullanıldığını biliyorum. HTML büyük ölçüde buradan türedi HTML'deki ilginç nokta, bir tür işaretleme dilinin onlarca yıl ortalıkta dolaştıktan sonra Berners-Lee'nin buna hiperlink eklemiş olması
    • Şimdi adı description list değil mi?

  • Dünyanın ilk web sitesi `` öğesini çok kullanıyor https://info.cern.ch/hypertext/WWW/TheProject.html https://info.cern.ch/ ise gerçek ilk web sitesine bağlam ve yön veren bir tür landing page

  • Native GUI toolkit'lerin hepsi öldü ama artık insanlar tek bir HTML öğesi hakkında uzun denemeler yazabiliyor. Buna gelişme mi demeliyiz emin değilim

  • HTML5'ten önce buna definition list deniyordu ve ``in başlangıçta yalnızca terim ve tanımlardan oluşan glossary'leri temsil etmesi amaçlanmıştı; bunu şimdi öğrendim. Demek 10 yıldır adını yanlış söylüyormuşum

    • b artık “bring attention to” muymuş. Vay be
    • Yalnız değilsin. Bu hafta bunu ikinci görüşüm ve ilkinde yazım hatası sanmıştım
    • Definition list adının değiştiğini şimdi öğrendim
    • HTML5'in hangi yıl standartlaştığını kontrol etmek istemiyorum. Muhtemelen 10 yıldan da eski ;)

  • Güzel yazı. Çok küçük bir itiraz olarak, small öğesi alt başlıklar için kullanılmamalı; onun yerine hgroup öğesi kullanılmalı small öğesi, küçük puntolu ek yorumlar gibi yan notları temsil eder. Küçük puntoda genelde feragatnameler, uyarılar, yasal kısıtlar ve telif hakkı bilgileri yer alır. Kaynak belirtme ya da lisans gereksinimlerini karşılama için de bazen kullanılır (https://html.spec.whatwg.org/multipage/text-level-semantics....)

  • Ekran okuyucuların `` desteğinin ne kadar iyi olduğuna dair faydalı bir not var: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...

  • DnD özellik kağıdındaki son örnek, ``in iç içe kullanılmasının da geçerli olup olmadığını merak ettirdi Mesela Actions ... gibi bir şey yapılabilir mi?

  • i seviyorum. En azından geçmişte tabloların gibi yanlış kullanılması daha yaygındı ve tablo işaretlemesinin hantallığı birkaç div kullanmaktan daha kötü

    • Gereksiz kapanış etiketlerini atlarsanız o kadar da hantal değil first second what ever Bence herhangi bir Markdown tablo sözdiziminden daha basit ve temiz
    • Doğru. Ama tabloların `` taklidi yapmaya zorlanması, tablo kötüye kullanımının daha iyi örneklerindendi
    • Ben hep ``i tablonun tek bir satırı gibi düşündüm