Tasarım kararı - neden <p> olmadan </p> üretelim?


14

tl; Dr.

Html üreten bazı yaygın olarak kullanılan programlar, tarayıcının paragrafları düzgün bir şekilde kapatacağını varsayarsak, yalnızca açılış paragraf etiketlerini oluşturur ve kapanış olanları oluşturmaz.

Görünüşe göre, tarayıcıların paragrafları düzgün bir şekilde kapatacağı varsayımı doğru değil. Benim yorumum doğru mu? Daha genel olarak, bu tür bir karara hangi ödünleşmeler dahildir?


Moinmoin kaynak koduna göz atarken, aşağıdaki kod satırı gözüme çarptı:

# We only open those tags and let the browser auto-close them:
_auto_closing_tags = set(['p'])

( kaynak )

Uygulamanın geri kalanını okuduktan sonra, kendimi, evet, gerçekten, moinmoin sayfalarından biri için html kodu oluşturduğunda, uygun olduğunda paragraf açık etiketleri oluşturacak ve aynı zamanda paragraf etiketleri kapatır (önemsiz bir şekilde yapabilmesine rağmen).

Özel, oldukça sıradışı olan kullanım durumum için bu davranış doğru değil. Bir hata raporu göndermeye ve / veya davranışı değiştirmeye cazipim. Ancak, bu tasarım kararının düşünceli bir şekilde verildiği anlaşılıyor. Genel olarak doğru davranış olup olmadığını anlayabilmek için html standardının karmaşıklıklarında veya çeşitli tarayıcı uygulamalarında yeterince bilgili değilim ve bu davranışı düzeltme / değiştirme içgüdümün olabileceğini hissetmek için yanıltıcı.

Bu kod tarayıcı uygulamaları hakkında geçerli bir varsayım yapıyor mu? Oluşturulan html geçerli mi? Daha genel olarak, burada hangi ödünç eksik olabilir?


2
Mevcut cevaplara rağmen, bu moronik bir tasarıma benziyor. “Kabul ettiğiniz şeylerde liberal ve gönderdiğiniz şeylerde muhafazakar olun”. Ayrıca tamamen gereksizdir. Ben ediyorum kesinlikle MoinMoin bir (sert ifadeli) hata raporu gönderin. En azından bu bilinçsiz davranışı açıkça belgelemeli ve yorumlamalıdırlar.
Konrad Rudolph

Yanıtlar:


33

pÖğeler için bitiş etiketleri HTML'de isteğe bağlıydı ve yalnızca XHTML'de gerekliydi. Ancak, HTML5 taslağı, pbitiş etiketinin gerçekten isteğe bağlı olduğu durumlar için bir dizi koşul sunar :

P öğesinin hemen ardından bir adres, makale, kenara, blok alıntı, dir, div, dl, fieldset, altbilgi, form, h1, h2, h3, h4, h5, h6, başlık gelirse bir p öğesinin bitiş etiketi atlanabilir , hgroup, hr, menu, nav, ol, p, pre, bölüm, tablo veya ul, element veya ana öğede daha fazla içerik yoksa ve üst öğe bir öğe değilse.

Kaynak: HTML5 spesifikasyonu

Bu şu ana kadar duyduğum tek argüman belirterek, için için uç etiketlerini atlayarak pelemanları belge boyutudur. Belgeniz için bunun mantıklı olup olmadığına karar vermek tamamen size bağlıdır. Şahsen, bitiş etiketinin isteğe bağlı olduğu için gereksinimleri karşılamamış olsam da, tüm isteğe bağlı bitiş etiketlerini dahil etme eğilimindeyim.


5
Büyük akıllar benzer düşünür, sanırım. :)
Robert Harvey

@RobertHarvey Bu turu 12 saniye kazanıyorsunuz ...
yannis

2
Bitiş etiketlerini atlamaktan başka bir argüman: belge yapısından belirgindir ve kötüye kullanıldıklarında sahte boşluk da sunabilirler.
Jon Purdy

1
Son etiketleri atlayabilmek açıkça HTML'nin dayandığı SGML'nin bir tasarım özelliğiydi. Ayrıca açıkça XHTML'nin dayandığı bir XML özelliği DEĞİLDİR.
Alan Shutko

4
Çok gördüğüm bir argüman daha temiz görünüyor. Özellikle <li>etiketler söz konusu olduğunda, etiketler daha çok madde işaretleri gibi davranır.
DisgruntledGoat

16

HTML5 W3C spesifikasyonu özellikle belirtmektedir:

P öğesinin hemen ardından bir adres, makale, kenara, blok alıntı, dir, div, dl, fieldset, altbilgi, form, h1, h2, h3, h4, h5, h6, başlık gelirse bir p öğesinin bitiş etiketi atlanabilir , saat, menü, gezinti, ol, p, ön, bölüm, tablo veya ul öğesi olarak veya üst öğede daha fazla içerik yoksa ve üst öğe bir öğe değilse.

Bu nedenle, temelde, etiketin kapatılmasının karmaşıklığından (büyük ya da küçük olabilir) birçok yol sağlanmıştır. Uygun tarayıcı uygulamalarının bu istisnalara uyması gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.