HTML: İsteğe bağlı kapanış etiketleri dahil mi yoksa hariç tutuluyor mu?


149

Bazı HTML 1 kapatma etiketleri isteğe bağlıdır , yani:

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

Not: Eklenmesi yasak olan kapanış etiketleriyle karıştırılmamalıdır , yani:

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Not: xhtml HTML'den farklıdır. xhtml, her öğenin bir kapatma etiketine sahip olmasını gerektiren bir xml biçimidir . Bir Kapanış etiketi edilebilir yasak html içinde, henüz zorunlu içinde xhtml.

İsteğe bağlı kapanış etiketleri

  • ideal olarak dahil edildi , ancak unutursanız kabul edeceğiz veya
  • ideal olarak değil dahil, ancak onları koyarsanız biz onları kabul edeceğiz

Başka bir deyişle, gerektiği onları dahil, yoksa gerektiğini değil onları da?

Eleman etiketleri isteğe olma kapanmasıyla ilgili HTML 4.01 Spec görüşmeler , ancak bunları içermez onları ya tercih içerecek şekilde tercih olmadığını söylemez.

Öte yandan DevGuru hakkında rastgele bir makale şöyle diyor :

Bitiş etiketi isteğe bağlıdır. Ancak dahil edilmesi tavsiye edilir.

Sormamın nedeni , uyumluluk nedenleriyle isteğe bağlı olduğunu bilmeniz ; ve eğer yapabilirlerse onları ( zorunlu | yasak ) yaparlardı .

Başka bir deyişle: HTML 1, 2, 3, şu anda isteğe bağlı olan bu kapatma etiketleriyle ilgili olarak ne yaptı. HTML 5 ne yapar? Ve ne olmalıdır ben do?

Not

HTML'deki bazı öğelerin kapatma etiketlerine sahip olması yasaktır . Buna katılmayabilirsiniz, ancak bu şartname ve tartışmaya açık değil. İsteğe bağlı kapanış etiketleri ve niyetin ne olduğunu soruyorum .

Dipnotlar

1 HTML 4.01


4
Zor soru ... w3c önerilerinin bazıları her ikisini de yapan örnekler bile içerir: w3.org/TR/html401/struct/global.html#id-and-class İlk örnekte kapatma </p>etiketleri ve ikincisi bunları atlıyor!
Richard JP Le Guen

Sadece netleştirmek için - HTML5 yasak etiketleri durumunda, "açık" / XML geçerli çözüm onları kapatmaktır />gibi, <meta charset="utf-8" />olsa bile <meta charset="utf-8">geçerli HTML5 nedir?
cboettig

@cboettig Evet. <meta charset="utf-8" />olduğu geçersiz html, o gerekmektedir olmak <meta charset="utf-8">. Öte yandan Açık <meta charset="tuf-8">olan geçersiz xhtml, bu olmalıdır olmak<meta charset="utf-8" />
Ian Boyd

@IanBoyd gerçekten mi? HTML5'te Poliglot html / xhtml için taslak W3C manuel kullanmayı diyor <meta charset="UTF-8"/>kapanış etiketiyle. Aksi takdirde, polyglot veya xhtml hiç html5 ve xml olarak nasıl doğrulanabilir?
cboettig

@cboettig Haklısın. Polyglot İşaretlemesi (örn. HTML Uyumlu XHTML Belgeleri ) geçerli HTML 4.01 olamaz . HTML5 (hala devam etmekte olan bir çalışma), Void öğeleri (bitiş etiketi bulunmayan öğeler ) kavramına sahiptir . Muhtemelen tarayıcıların çoğu naziktir ve biçimlendirme hatalarınızı affedecektir.
Ian Boyd

Yanıtlar:


49

İsteğe bağlı olanların tümü, bitiş etiketine ihtiyaç duymadan, bittikleri yerde anlamsal olarak net olması gerekenlerdir. EG'nin her biri, hemen öncesinde bir tane yoksa <li>anlamına gelir </li>.

Yasak bitiş etiketlerinin hemen ardından bitiş etiketleri gelecektir, böylece <img src="blah" alt="blah"></img>her seferinde yazmak zorunda kalabilirsiniz .

Neredeyse her zaman isteğe bağlı etiketleri kullanmak (çok iyi bir neden olmadığı sürece) çünkü daha okunabilir ve güncellenebilir koda borç veriyor.


18
şimdi görüyorum. <LI>mermi gibidir. Kimse tüm madde işaretli bir noktayı sarmak istemez <LI>...</LI>. Bu şekilde, LIişaretleme sırasında insanların doğal olarak yazacakları maçlar. Sames paragraf işaretine ( <P>) gider , kelime işlemede paragrafın başına paragraf işareti eklersiniz ; ve her birinin sonunda değil. Bu yorumda kapanış etiketleri isteğe bağlıdır, çünkü normal bir kişi bunlara sahip olmayı düşünmez. Artı, eleman kendisi hiçbir içeriğe sahip - eleman olan içeriği.
Ian Boyd

8
Tarafından Ne demek ben hemen hemen her zaman kullanmak İsteğe bağlı etiketler - Bunu demek istiyorsun dahil bitiş etiketi, yoksa bunu dışarıda bırakın ? (Bunu izlenimini aldım dahil Cevabını okurken, bunu - ama yukarıdaki açıklama Ian Boyd bana o izlenimi verir dışlamak onu.)
KajMagnus

3
@IanBoyd Son paragraf için mi?
Pacerier

22
@Pacerier İnsanlar yüzlerce yıldır metin paragrafları yazıyor. Paragraf sona erdiğinde kimsenin kafası karışmadı.
Ian Boyd

4
Gerçek referans belgelerini bulmaya çalışırken bu cevabı bulanlar için HTML5 için ilgili bağlantı: w3.org/TR/html5/syntax.html#optional-tags
Mike 'Pomax' Kamermans

59

Açık etiketlerin yardımcı olduğu durumlar vardır, ancak bazen gereksiz bilgeliktir.

HTML spesifikasyonunun etiketleri atlamanın ne zaman geçerli olacağını açıkça belirttiğinden, bu her zaman bir hata değildir.

Örneğin, asla ihtiyacınız yok </body></html>. Hiç kimse <tbody>açıkça (XHTML'nin istisna yaptığı noktaya) koymayı hatırlamıyor .

Buna gerek yok </head><body>aslında arama komut dosyalarını DOM-manipüle yoksa <head>(o zaman açıkça kapatmak için daha iyi bir zımni sonu için kurallar nedeniyle, <head>size sürpriz olabilir).

İç içe listeler aslında olmadan daha iyidir </li>, çünkü o zaman hatalı ul > ulağaç oluşturmak daha zordur .

Geçerli:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Geçersiz:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

Ayrıca, tüm öğeleri kapatmaya çalışsanız da çalışmasanız da bitiş etiketlerinin ima edildiğini unutmayın. Bitiş etiketleri koymak, ayrıştırmayı otomatik olarak daha sağlam hale getirmez:

<p>foo <p>bar</p> baz</p>

şu şekilde ayrıştırılacaktır:

<p>foo</p><p>bar</p> baz

Yalnızca belgeleri doğruladığınızda yardımcı olabilir.


4
Bekle, neden <p>foo <p>bar</p> baz</p>iki iç içe petiket olarak ayrıştırılmıyor ?
Eric

19
Çünkü bir <P>eleman blok seviyesi elemanları içeremez ve <P>bir blok seviyesi elemanıdır. ( W3.org/TR/REC-html40/struct/text.html#edef-P ) "P öğesi bir paragrafı temsil eder. Blok düzeyinde öğeler (P'nin kendisi dahil) içeremez."
Ian Boyd

1
@IanBoyd CSS kurallarına bakılmaksızın blok düzeyinde öğeler içeremez mi demek istediniz?
Pacerier

6
@Pacerier CSS, DOM'u hiçbir şekilde etkileyemez. Önce DOM ayrıştırılır ve sonra CSS bunu görüntüler. CSS blockgörüntüleme, HTML'nin blok düzeyi içeriğinden tamamen farklı bir şeydir (yalnızca HTML blok düzeyi öğelerinin çoğu varsayılan olarak CSS blokları olarak görüntülenir).
Kornel

2
@ anton1980 Hayır, bu aynı değil. Atlanan isteğe bağlı kapatma etiketlerinin kullanımı açıkça belirtilir ve tüm uyumlu tarayıcılarda güvenilir bir şekilde çalışır. OTOH bir makyaj <t>gibi çalışmaz <title>.
Kornel

18

Çeşitli çelişkileri anlamanız için buraya HTML geçmişinde yardımcı olacak bazı bağlantılar ekliyorum. Bu, sorunuzun cevabı değil, ancak bu çeşitli özetleri okuduktan sonra daha fazlasını öğreneceksiniz.

Dalışa HTML5'ten bazı alıntılar :

“Kırık” HTML biçimlendirmesinin hala web tarayıcılarında çalıştığı gerçeği, yazarların bozuk HTML sayfaları oluşturmasına neden oldu. Bir sürü bozuk sayfa. Bazı tahminlere göre, bugün web'deki HTML sayfalarının% 99'undan fazlasında en az bir hata var. Ancak bu hatalar tarayıcıların görünür hata mesajları görüntülemesine neden olmadığından, kimse bunları düzeltemez.

W3C bunu web ile ilgili temel bir sorun olarak gördü ve düzeltmeye başladılar. 1997'de yayınlanan XML, müşterileri affetme geleneğinden ayrıldı ve XML tüketen tüm programların “iyi biçimlilik” olarak adlandırılan hataları ölümcül olarak ele alması gerektiğini belirtti. İlk hatada başarısız olma kavramı , yasalarının nispeten küçük ihlalleri nedeniyle ölüm cezasını başlatan Yunan lideri Draco'nun ardından “acımasız hataların ele alınması” olarak biliniyordu . W3C, HTML'yi bir XML kelime haznesi olarak yeniden biçimlendirdiğinde, yeni application/xhtml+xmlMIME türüyle sunulan tüm belgelerin acımasız hata işlemeye tabi olmasını zorunlu kıldılar. XHTML sayfanızda tek bir iyi biçimlilik hatası bile olsa […] web tarayıcılarının işlemeyi durdurmak ve son kullanıcıya bir hata mesajı görüntülemek dışında bir seçeneği yoktur.

Bu fikir evrensel olarak popüler değildi. Mevcut sayfalarda tahmini% 99'luk bir hata oranı, son kullanıcıya sürekli hata görüntüleme olasılığı ve maliyeti haklı çıkarmak için XHTML 1.0 ve 1.1'deki yeni özelliklerin eksikliği, web yazarları temelde göz ardı etti application/xhtml+xml. Ancak bu, XHTML'yi tamamen göz ardı ettikleri anlamına gelmez. Kesinlikle hayır. XHTML 1.0 spesifikasyonunun Ek C'si, dünyanın web yazarlarına bir boşluk bıraktı: “XHTML sözdizimine benzeyen bir şey kullanın, ancak text/htmlMIME türüyle sunmaya devam edin .” Binlerce web geliştiricisinin yaptığı tam da buydu: XHTML sözdizimine "geçtiler", ancak bir metin / html MIME türü ile sunmaya devam ettiler.

Bugün bile milyonlarca web sayfası XHTML olduğunu iddia ediyor. Bunlar ilk satırında, kullanım küçük etiket adları özellik değerlerinin etrafında kullanımı tırnak üzerinde XHTML doctype ile başlar ve benzeri boş elemanlar sonra eğik çizgi ekleyin <br />ve <hr />. Ancak bu sayfaların yalnızca küçük bir kısmı, application/xhtml+xmlXML'in acımasız hata işlemesini tetikleyecek olan MIME türüyle sunulur . MIME türüyle sunulan tüm text/htmldokümanlar, sözdizimi veya kodlama stili ne olursa olsun, "affedici" bir HTML ayrıştırıcı kullanılarak ayrıştırılır, biçimlendirme hatalarını sessizce yok sayılır ve sayfalar bile son kullanıcıları (veya başkalarını) asla uyarmaz teknik olarak kırıldı.

XHTML 1.0 bu boşluğu içeriyordu, ancak XHTML 1.1 onu kapattı ve hiç bitirilmemiş XHTML 2.0, acımasız hata işleme geleneğini sürdürdü. İşte bu yüzden XHTML 1.0 olduğunu iddia eden milyarlarca sayfa ve XHTML 1.1 (veya XHTML 2.0) olduğunu iddia eden bir avuç sayfa var. Gerçekten XHTML kullanıyor musunuz? MIME türünüzü kontrol edin. (Aslında, hangi MIME türünü kullandığınızı bilmiyorsanız, hala kullandığınızı garanti edebilirim text/html.) Sayfalarınızı MIME türüyle sunmuyorsanız application/xhtml+xml, “XHTML” yalnızca adda XML'dir.

Gelişen HTML ve HTML formlarını öneren insanlar iki seçenekle karşı karşıya kaldılar: vazgeçmek ya da W3C dışında çalışmalarına devam etmek. İkincisini seçtiler, whatwg.orgetki alanını kaydettirdiler ve Haziran 2004'te WHAT Çalışma Grubu doğdu .

NE çalışma grubu sessizce başka şeyler üzerinde de çalışıyordu. Bunlardan biri, başlangıçta HTML formlarına yeni denetim türleri ekleyen Web Forms 2.0 olarak adlandırılan bir özellikti . ( Bir Çılgınlık Formundaki web formları hakkında daha fazla bilgi edineceksiniz .) Bir diğeri, doğrudan mod çizim tuvali ve eklentiler olmadan ses ve video için yerel destek gibi önemli yeni özellikleri içeren “Web Uygulamaları 1.0” adlı bir taslak özellikti .

Ekim 2009'da W3C , XHTML 2 Çalışma Grubunu kapattı ve kararlarını açıklamak için bu ifadeyi yayınladı :

W3C, Mart 2007'de HTML ve XHTML 2 Çalışma Gruplarını duyurduğunda, XHTML 2 pazarını izlemeye devam edeceğimizi belirttik. W3C, HTML'nin geleceği hakkında topluma açık bir sinyalin önemini kabul ediyor.

XHTML 2 Çalışma Grubunun yıllar içindeki katkılarının değerini kabul etsek de, katılımcılar ile görüştükten sonra, W3C yönetimi Çalışma Grubu sözleşmesinin süresinin dolmasına izin vermemeye karar verdi ve onu yenilememeye karar verdi.

Kazanan olanlar gemi olanlar.


12

Sormamın nedeni, uyumluluk nedenleriyle isteğe bağlı olduğunu bilmeniz; ve eğer yapabilirlerse onları (zorunlu | yasak) yaparlardı.

Bu ilginç bir çıkarım. Bunu okumam, bir etiketin neredeyse her zaman güvenilir bir şekilde çıkartılabileceği, etiketin isteğe bağlı olduğu. Tasarım, niyetin yazmayı hızlı ve kolay hale getirmek olduğunu gösteriyor.

HTML 1, 2, 3, şu anda isteğe bağlı olan bu kapatma etiketleriyle ilgili olarak ne yaptı?

HTML 2 için DTD , orijinal HTML DTD ile birlikte her yerde isteğe bağlı başlangıç ​​ve bitiş etiketlerine sahip olan RFC'ye yerleştirilmiştir.

HTML 3 terk edildi (tarayıcı savaşları sayesinde) ve yerine HTML 3.2 (web'in o anki mevcut durumunu tanımlamak için tasarlandı) verildi.

HTML 5 ne yapıyor?

HTML 5 en başından itibaren "inek yollarını döşemeye" yönelikti.

Peki ne yapmalıyım?

Ah, şimdi bu öznel ve tartışmacı :)

Bazı insanlar, açık etiketlerin okuyucunun gözünün önünde olması sayesinde okunabilirlik ve sürdürülebilirlik için daha iyi olduğunu düşünmektedir.

Bazı insanlar, editör etiketlerini düzenleyiciyi karıştırmamaktan dolayı okunabilirlik ve sürdürülebilirlik için daha iyi olduğunu düşünmektedir.


1
+1 "güvenilir bir şekilde çıkartılmış" kavramını düşünmemiştim. Bu, şu ya da bu şekilde herhangi bir niyetin olmadığı fikrini savunuyor. şartnamenin mevcut HTML içeriği ve HTML spesifikasyonlarıyla mümkün olduğunca uyumlu olmaya çalıştığı varsayılmıştır.
Ian Boyd

Üzgünüm Dave, aslum'a verdim; Temsilciye ihtiyacı var :) Ama aynı fikre sahipsiniz, daha bağlantılı ve alıntılanmış içerik. Ama güzel cevap.
Ian Boyd

8

HTML 5 ne yapıyor?

Bu sorunun cevabı W3C Çalışma Taslağı'ndadır: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

Peki ne yapmalıyım?

Bu bir stil meselesi. Bu beni titiz ve olmaya yardımcı olduğu asla omit bitiş etiketleri denemek değil gerekli olan omit etiketleri.


Taslak HTML 5 spesifikasyonunun bağlantısı ve ilgili bölüm için +1. Ama html 5 öyle ya da böyle demiyor.
Ian Boyd

6

Gereksizse, dışarıda bırakın.

Bir amaca hizmet ediyorsa (IDE'nizi uygulamak veya gözlerinizi uygulamak gibi görünüşte önemsiz bir amaç bile), bırakın.

İyi tanımlanmış bir özellikte davranışı etkilemeyen isteğe bağlı öğeleri görmek nadirdir. Tabii ki, "yorumlar" hariç. Ancak HTML spesifikasyonu bir tasarım spesifikasyonundan daha az ve mevcut büyük uygulamaların durumunun bir belgesidir. Dolayısıyla, bir öğe HTML'de isteğe bağlı olduğunda ve hiçbir amaca hizmet etmediği zaman, isteğe bağlı doğanın yalnızca belirli bir tarayıcıdaki bir tuhaflığın dokümantasyonu olduğunu tahmin edebiliriz.

Yukarıda bağlantılı HTML-5 spec RFC bölümüne baktığınızda, isteğe bağlı etiketlerin garip bir şekilde yorumların varlığına bağlı olduğunu görürsünüz! Bu size yazarların tasarım şapka giymediğini söylemelidir. Bunun yerine büyük uygulamalarda “tuhaflıkları belgelemek” oyununu oynuyorlar. Bu yüzden spesifikasyonu çok ciddiye alamayız.

Yani çözüm şudur: Terlemeyin. Gerçekten önemli bir şeye geçin. :)


5

Bence en iyi cevap okunabilirlik veya hata tespiti için kapanış etiketlerini eklemektir. Ancak, çok sayıda oluşturulan HTML'niz varsa (örneğin, veri tabloları), isteğe bağlı etiketleri atlayarak önemli bant genişliğinden tasarruf edebilirsiniz.


2
Richard: Derin iç içe geçmiş yapılarınız olduğunda, hataları bulmak sizin için çok daha kolay çünkü kapanış etiketleri niyet hakkında daha fazla bilgi veriyor.
Gabe

1
Bence "kapanış etiketleri niyet hakkında daha fazla bilgi verir" bu soruya en kısa ve özlü cevaptır. Öyle ya da böyle iyi bir neden olduğunu savunuyor.
squarecandy

4

Benim önerim, çoğu isteğe bağlı kapatma etiketini ve kurtarabileceğiniz tüm isteğe bağlı özellikleri atlamanızdır. Birçok IDE şikayet edecek, bu nedenle bunlardan bazılarını atlayamayabilirsiniz, ancak genellikle daha küçük dosya boyutu ve daha az dağınıklık için daha iyidir. Kod jeneratörleriniz varsa, orada son etiketleri atlayın çünkü ondan iyi bir boyut küçültme alabilirsiniz. Genellikle şu ya da bu şekilde önemli değil.

Ama önemli olduğunda harekete geçin. Son zamanlardaki bazı çalışmalarda, öğenin metninin metinle değer. Yaklaşık 200 etiketim var. Bunu tamamen başka bir şekilde uygulayabilirim, ancak bu daha fazla iş ($$$) olurdu, bu yüzden bu sayfayı kolayca daha duyarlı hale getirmeme izin veriyor.

Sadece meraktan, onlara ihtiyaç duymayan özniteliklerin tırnaklarını kaldırırsam 20 KB kaydedebilirim, ancak IDE'm (Visual Studio) beğenmediğini fark ettim. Ayrıca ASP.NET'in oluşturduğu gerçekten uzun kimliğin dosyamın% 20'sini oluşturduğunu bulmak beni şaşırttı.

HTML'nin herhangi bir ilgili kısmını kesinlikle geçerli hale getirebileceğimiz fikri ilk etapta yanlış yönlendirildi, bu yüzden sizin ve müşterileriniz için en uygun olanı yapın. Gördüğüm veya kullandığım çoğu araç xhtml ürettiklerini söyleyecek, ancak gerçekten% 100 çalışmıyorlar ve sıkı sıkıya bağlı kalmanın herhangi bir yararı yok.


İsteğe bağlı son etiketleri atlamayı neredeyse kabul edemiyorum, ancak özelliklerde alıntıları atlamayı oldukça kötü bir fikir olarak görüyorum. Sitenizi bazı tarayıcılara bu şekilde girme riskiyle karşı karşıyasınız. 800kb html dosyalarınız varsa ciddi bir yanlışlık yapıyorsunuz.
Christoph

2
@Christoph: İsteğe bağlı son etiketleri ( </p>veya gibi </li>) atlamak , HTML spesifikasyonuna göre gayet iyi. Tarayıcı bunu anlamıyorsa, tarayıcıda sorun var.
Konrad Borowski

2

Şahsen ben XHTML hayranıyım ve ghoppe gibi, "Son etiketleri asla atlamaya çalışmam çünkü titiz olmam ve gerekli etiketleri atlamama yardımcı oluyor."

fakat

Kasıtlı olarak HTML 4.n kullanıyorsanız, geçerliliğin aksine iyi biçimlilik kavramı bir XML konsepti olduğundan, bunları dahil etmenin belgeyi tüketmeyi kolaylaştırdığını iddia edemezsiniz ve bazı yakın etiketleri yasakla . Yani tek sorun geçerlilik kazanıyor ... ve onlarsız hala geçerliyse ... bant genişliğinden de tasarruf edebilirsiniz, değil mi?


2

Bitiş etiketlerini kullanmak, davranışları kardeş öğelere bağlı olmadığından parçalarla uğraşmayı kolaylaştırır. Bu sebep tek başına yeterince zorlayıcı olmalıdır. Herkes artık monolitik html belgeleri ile ilgileniyor mu?


1

C # gibi bazı köşeli parantez dillerinde, yalnızca iki satır uzunluğundaysa, bir if ifadesinin etrafındaki kıvırcık parantezleri atlayabilirsiniz. Örneğin...

eğer ([koşul])
    [kod]

ama bunu yapamazsın ...

eğer ([koşul])
    [kod]
    [kod]

üçüncü satır if ifadesinin bir parçası olmaz. okunabilirliği incitir ve hatalar kolayca tanıtılabilir ve bulunması zor olabilir.

aynı nedenlerle, tüm etiketleri kapatın. img etiketi gibi etiketlerin, ayrı bir kapatma etiketiyle değil, yine de kapatılması gerekir.


Çok zor olan HTML örneğini verebilir misiniz? Deneyimlerime göre, isteğe bağlı bitiş etiketleri o kadar aldatıcı değil.
Kornel

Birkaç yıl önce IE7 ile ilgili bir sorun yaşadığımı hatırlıyorum, içerdiği metinden ayrı bir satırda bir açılış li etiketi buldum, kapanış li olmadan, IE7 büyük bir mermi gibi tüm mermileri tedavi etti. etiketi ve metni bir satıra koymak veya etiketi kapatmak sorunu çözer. Yine de bunu kopyalayamıyorum, bu yüzden muhtemelen css ile ilgili bir şey vardı. ama bunu "tamamen kız arkadaşım var ... Kanada'da" olarak kabul ettiğim için seni suçlamam. hikaye.
MiguelR

0

Bir HTML ayrıştırıcısı yazıyorsanız, isteğe bağlı kapanış etiketleri içeren HTML'yi veya içermeyen HTML'yi ayrıştırmak daha kolay olur mu? İsteğe bağlı kapanış etiketlerinin mevcut olmasını kolaylaştırır, çünkü kapanış etiketinin nerede olması gerektiğine karar vermek zorunda kalmazdım.

Bu nedenle, tarayıcının HTML ayrıştırıcısı için daha az çalışma oluşturduğum için, her zaman isteğe bağlı kapanış etiketlerini ekliyorum - sayfamın daha hızlı görüntülenebileceği teorisine.


1
Katılmıyorum; geçerliliğin aksine iyi biçimlilik kavramı yalnızca XML konseptidir ve yakın etiketleri yasak olan öğeleriniz olduğunda ilgisiz hale gelir .
Richard JP Le Guen

1
Bunu anlıyorum, ancak HTML etiketiniz olmasa da, oluşturulan DOM öğesinin hem bir başlangıcı hem de bir sonu var. <li>Kapatma etiketi olmayan bir etiket eklerseniz, bir noktada tarayıcının öğenin nerede biteceğine karar vermesi ve o noktaya bir bitiş etiketi koymuş gibi davranması gerekir. Bu nispeten önemsiz bir mantık olabilir, ancak "bazı" hala "hiçbiri" den daha fazladır ve isteğe bağlı son etiketleri bırakmanın tarayıcı için onları dahil etmekten daha fazla iş yaptığını varsaymanın mantıksız olduğunu düşünmüyorum.
Joel Mueller

Bu ilginç bir nokta ama yine de katılmıyorum; yakın etiketler ayrıştırıcı orada bir noktaya ulaşır, böylece zaman ... onlar gerekli olacak gibi isteğe bağlı ve doğrulama kurallarına göre böylece örtülü olan vardır , doğrulama göre bir kapanış etiketi olması o iddia edilemez olduğunu tüketen görevi bir kapanış etiketi (varsa) etiketi yavaşlatır mı?
Richard JP Le Guen

@Richard - Sanırım bu belirli bir tarayıcıdaki gerçek uygulamaya bağlıdır, ancak bir öğenin nerede bitmesini istediğinize dair açık olmanın, tarayıcıya anlamaya çalışmasını söylemekten daha kötü olacağı fikrini kabul etmekte zorlanıyorum. sen.
Joel Mueller

@RichardJPLeGuen Sanırım her şey kuralların tam olarak nasıl göründüğüne bağlı. Kapatırken</table> ve yığınınız içerdiğinde <table><tbody><tr><td>, eşleşene kadar her şeyi kapatabilirsiniz <table>. Benzer şekilde, <p>saat olmayan bir bağlamda açmak için . Ama çok daha zor vakalar olabilir, bilmiyorum.
maaartinus

-1

Hissettiğiniz her şeyi yapın, kodu daha okunabilir ve bakım yapılabilir hale getirir.

Şahsen ben her zaman kapatmak için eğimli olacak <td>ve <tr>, ama ben rahatsız asla <li>.


1
özgün tasarım kararı konusunda biraz rehberlik etmeyi umuyordum ve eğer yapabilirlerse x yapardı .
Ian Boyd

Arasındaki fark nedir <td>ve <li>bu sizi rahatsız etmiyor <li>mu? Benim için çok az fark var.
ghoppe

Teknik bir fark yok, tamamen öznel. Eğer td ve tr'yi kapatırsam HTML'yi daha iyi okuyabileceğimi hissediyorum. Ama li ile olan ihtiyacı hiç hissetmedim.
Matthew Wilson

-2

Yasak kapanış türleri için böyle sözdizimini kullanın: <img />With />xml kabul edilen etiketi kapatmak için


1
HTML4'te çalışmaz (biraz farklı bir şey yapan belirsiz SGML sözdizimiyle eşleşir). HTML5'te buna izin verilir, ancak anlamsızdır.
Kornel
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.