HTML: Sertakan, atau kecualikan, tag penutup opsional?

149

Beberapa tag penutup HTML ¹ adalah opsional , yaitu:

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

Catatan: Jangan bingung dengan tag penutup yang dilarang untuk dimasukkan, yaitu:

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

Catatan: xhtml berbeda dari HTML. xhtml adalah bentuk xml, yang mengharuskan setiap elemen memiliki tag penutup. Tag penutup dapat dilarang dalam html, namun wajib dalam xhtml.

Apakah tag penutup opsional

dimasukkan secara ideal , tetapi kami akan menerimanya jika Anda lupa, atau
idealnya tidak termasuk, tetapi kami akan menerimanya jika Anda memasukkannya

Dengan kata lain, haruskah saya memasukkannya, atau tidakkah saya harus memasukkannya?

Spesifikasi HTML 4.01 berbicara tentang penutupan tag elemen sebagai opsional , tetapi tidak mengatakan apakah lebih disukai untuk memasukkannya, atau lebih disukai untuk tidak memasukkannya.

Di sisi lain, artikel acak tentang DevGuru mengatakan :

Tag akhir adalah opsional. Namun, disarankan untuk disertakan.

Alasan saya bertanya adalah karena Anda tahu itu opsional untuk alasan kompatibilitas; dan mereka akan membuatnya ( wajib | dilarang ) jika mereka bisa.

Dengan kata lain: Apa yang dilakukan HTML 1, 2, 3 terkait dengan tag penutup yang sekarang opsional ini. Apa yang dilakukan HTML 5? Dan apa yang harus saya lakukan?

Catatan

Beberapa elemen dalam HTML dilarang memiliki tag penutup. Anda mungkin tidak setuju dengan itu, tapi itu spesifikasinya, dan itu tidak cocok untuk diperdebatkan. Saya bertanya tentang tag penutup opsional , dan apa tujuannya.

Catatan kaki

¹ HTML 4.01

html html4

— Ian Boyd
sumber

4

Pertanyaan sulit ... beberapa rekomendasi w3c bahkan menyertakan contoh yang dapat melakukan keduanya: w3.org/TR/html401/struct/global.html#id-and-class Contoh pertama memiliki </p>tag penutup dan yang kedua menghilangkannya!

— Richard JP Le Guen

Hanya untuk memperjelas - dalam kasus tag dilarang dalam HTML5, "eksplisit" / XML solusi yang valid adalah untuk menutup mereka dengan />, seperti <meta charset="utf-8" />meskipun <meta charset="utf-8">adalah HTML5 valid?

— cboettig

@ cboettig Ya. <meta charset="utf-8" />adalah valid html, itu harus menjadi <meta charset="utf-8">. Di sisi lain <meta charset="tuf-8">adalah valid xhtml, itu harus menjadi<meta charset="utf-8" />

— Ian Boyd

@IanBoyd sungguh? dalam HTML5? The W3C rancangan panduan untuk polyglot html / xhtml mengatakan untuk menggunakan <meta charset="UTF-8"/>dengan tag penutup. Kalau tidak, bagaimana polyglot atau xhtml bisa divalidasi sebagai html5 dan xml?

— cboettig

@ cboettig Anda benar. Markup Polyglot (yaitu Dokumen XHTML yang Kompatibel dengan HTML ) tidak dapat menjadi HTML 4.01 yang valid. HTML5 (masih dalam proses) memiliki gagasan elemen Void - elemen yang tidak dapat memiliki tag akhir . Agaknya sebagian besar peramban lunak, dan akan memaafkan kesalahan markup Anda.

— Ian Boyd

49

Yang opsional adalah semua yang semestinya jelas di mana mereka berakhir, tanpa perlu tag akhir. Masing-masing EG <li>menyiratkan a </li>jika tidak ada yang tepat sebelumnya.

Tag akhir terlarang semua akan segera diikuti oleh tag akhir mereka sehingga agak berlebihan jika harus mengetik <img src="blah" alt="blah"></img>setiap waktu.

Saya hampir selalu menggunakan tag opsional (kecuali saya memiliki alasan yang sangat bagus untuk tidak melakukannya) karena ini memberikan kode yang lebih mudah dibaca dan dapat diperbarui.

— aslum
sumber

18

saya melihatnya sekarang. <LI>seperti peluru. Tidak ada yang mau harus membungkus seluruh poin <LI>...</LI>. Jadi dengan cara itu LIcocok dengan apa yang biasanya ditulis orang selama markup. Sames berlaku untuk tanda paragraf ( <P>), dalam pengolah kata Anda menambahkan tanda paragraf di awal paragraf; dan tidak pada setiap akhir juga. Jadi dalam interpretasi ini tag penutup adalah opsional karena tidak ada orang normal yang berpikir untuk memilikinya. Plus, elemen itu sendiri tidak memiliki konten - elemennya adalah konten.

— Ian Boyd

8

Apa yang Anda maksud dengan saya hampir selalu menggunakan tag opsional - maksud Anda bahwa Anda menyertakan tag akhir, atau Anda meninggalkannya ? (Saya mendapat kesan bahwa Anda memasukkannya , ketika saya membaca jawaban Anda - tetapi komentar di atas oleh Ian Boyd memberi saya kesan bahwa Anda mengecualikannya .)

— KajMagnus

3

@IanBoyd Dan untuk paragraf terakhir?

— Pacerier

22

@Pacerier Orang telah menulis paragraf teks selama ratusan tahun. Tidak ada yang pernah bingung ketika paragraf berakhir.

— Ian Boyd

4

Tautan yang relevan untuk HTML5, bagi mereka yang menemukan jawaban ini ketika mencoba menemukan dokumentasi referensi yang sebenarnya: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

Ada kasus-kasus di mana tag eksplisit membantu, tetapi kadang-kadang itu tidak berguna.

Perhatikan bahwa spesifikasi HTML menentukan dengan jelas kapan valid untuk menghilangkan tag, jadi itu tidak selalu merupakan kesalahan.

Misalnya Anda tidak pernah membutuhkannya </body></html>. Tidak ada yang pernah ingat untuk menempatkan <tbody>secara eksplisit (ke titik XHTML membuat pengecualian untuk itu).

Anda tidak perlu </head><body>kecuali Anda memiliki skrip manipulasi DOM yang benar-benar mencari <head>(maka lebih baik untuk menutupnya secara eksplisit, karena aturan untuk akhir yang tersirat <head>dapat mengejutkan Anda).

Daftar bersarang sebenarnya lebih baik tanpa </li>, karena dengan begitu lebih sulit untuk membuat ul > ulpohon yang salah .

Sah:

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

Tidak valid:

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

Dan perlu diingat bahwa tag akhir tersirat apakah Anda mencoba untuk menutup semua elemen atau tidak. Menempatkan tag akhir tidak akan secara otomatis membuat parsing lebih kuat:

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

akan diuraikan sebagai:

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

Itu hanya dapat membantu ketika Anda memvalidasi dokumen.

— Kornel
sumber

4

Tunggu, mengapa <p>foo <p>bar</p> baz</p>tidak diuraikan sebagai dua ptag bersarang ?

— Eric

19

Karena <P>elemen tidak dapat mengandung elemen level blok, dan <P>merupakan elemen level blok. Dari ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "Elemen P mewakili sebuah paragraf. Elemen ini tidak dapat mengandung elemen level blok (termasuk P sendiri)."

— Ian Boyd

1

@IanBoyd Apakah maksud Anda tidak boleh mengandung elemen tingkat blok terlepas dari aturan CSS?

— Pacerier

6

@Pacerier CSS tidak dapat memengaruhi DOM dengan cara apa pun. DOM diuraikan terlebih dahulu, dan kemudian CSS menampilkannya. blockTampilan CSS adalah hal yang sama sekali berbeda dari konten level blok HTML (kebetulan saja sebagian besar elemen level blok HTML ditampilkan sebagai blok CSS secara default).

— Kornel

2

@ anton1980 Tidak, ini tidak sama. Penanganan tag penutup opsional yang dihilangkan dengan jelas ditentukan dan bekerja dengan andal di semua browser yang sesuai. OTOH yang dibuat-buat <t>tidak akan berfungsi <title>.

— Kornel

18

Saya menambahkan beberapa tautan di sini untuk membantu Anda dengan sejarah HTML, agar Anda dapat memahami berbagai kontradiksi. Ini bukan jawaban untuk pertanyaan Anda, tetapi Anda akan tahu lebih banyak setelah membaca berbagai intisari ini.

Beberapa kutipan dari Dive Into HTML5 :

Fakta bahwa markup HTML "rusak" masih berfungsi di browser web membuat penulis membuat halaman HTML yang rusak. Banyak halaman yang rusak. Menurut perkiraan, lebih dari 99% halaman HTML di web saat ini memiliki setidaknya satu kesalahan di dalamnya. Tetapi karena kesalahan ini tidak menyebabkan browser untuk menampilkan pesan kesalahan yang terlihat, tidak ada yang pernah memperbaikinya.

W3C melihat ini sebagai masalah mendasar dengan web, dan mereka berusaha memperbaikinya. XML, yang diterbitkan pada tahun 1997, berhenti dari tradisi memaafkan klien dan mengamanatkan bahwa semua program yang menggunakan XML harus memperlakukan kesalahan yang disebut "well-formedness" sebagai fatal. Konsep gagal pada kesalahan pertama dikenal sebagai "penanganan kesalahan kejam," setelah pemimpin Yunani Draco yang melembagakan hukuman mati untuk pelanggaran hukum yang relatif kecil. Ketika W3C memformulasi ulang HTML sebagai kosa kata XML, mereka mengamanatkan bahwa semua dokumen yang disajikan dengan application/xhtml+xmltipe MIME yang baru akan dikenakan penanganan kesalahan yang kejam. Jika ada kesalahan tunggal yang terbentuk dengan baik di halaman XHTML Anda [...] browser web tidak akan memiliki pilihan selain berhenti memproses dan menampilkan pesan kesalahan kepada pengguna akhir.

Ide ini tidak populer secara universal. Dengan perkiraan tingkat kesalahan 99% pada halaman yang ada, kemungkinan yang selalu ada menampilkan kesalahan kepada pengguna akhir, dan kelangkaan fitur baru di XHTML 1.0 dan 1.1 untuk membenarkan biaya, penulis web pada dasarnya mengabaikan application/xhtml+xml. Tapi itu tidak berarti mereka mengabaikan XHTML sama sekali. Oh, pasti tidak. Apendiks C dari spesifikasi XHTML 1.0 memberi celah bagi penulis web dunia: "Gunakan sesuatu yang terlihat seperti sintaks XHTML, tetapi tetap sajikan dengan text/htmltipe MIME." Dan itulah yang dilakukan oleh ribuan pengembang web: mereka "meningkatkan" ke sintaks XHTML tetapi terus menyajikannya dengan tipe MIME teks / html.

Bahkan hari ini, jutaan halaman web mengklaim sebagai XHTML. Mereka mulai dengan DOCTYPE XHTML pada baris pertama, menggunakan nama tag huruf kecil, menggunakan tanda kutip di sekitar nilai atribut, dan menambahkan garis miring setelah elemen kosong seperti <br />dan <hr />. Tetapi hanya sebagian kecil dari halaman ini yang disajikan dengan application/xhtml+xmltipe MIME yang akan memicu penanganan kesalahan kejam XML. Halaman apa pun yang disajikan dengan tipe MIME text/html- terlepas dari DOCTYPE, sintaksis, atau gaya pengkodean - akan diurai menggunakan parser HTML "maaf", dengan diam-diam mengabaikan kesalahan markup, dan tidak pernah memperingatkan pengguna akhir (atau siapa pun) bahkan jika halaman secara teknis rusak.

XHTML 1.0 termasuk celah ini, tetapi XHTML 1.1 menutupnya, dan XHTML 2.0 yang tidak pernah selesai melanjutkan tradisi yang membutuhkan penanganan kesalahan draconian. Dan itu sebabnya ada miliaran halaman yang mengklaim sebagai XHTML 1.0, dan hanya segelintir yang mengklaim sebagai XHTML 1.1 (atau XHTML 2.0). Jadi, apakah Anda benar-benar menggunakan XHTML? Periksa jenis MIME Anda. (Sebenarnya, jika Anda tidak tahu apa jenis MIME yang Anda gunakan, saya dapat menjamin bahwa Anda masih menggunakan text/html.) Kecuali Anda melayani halaman Anda dengan tipe MIME application/xhtml+xml, apa yang disebut "XHTML" adalah XML dalam nama saja.

Orang-orang yang telah mengusulkan pengembangan HTML dan formulir HTML dihadapkan pada dua pilihan: menyerah, atau melanjutkan pekerjaan mereka di luar W3C. Mereka memilih yang terakhir, mendaftarkan whatwg.orgdomain, dan pada Juni 2004, Kelompok Kerja APA lahir .

[APA] kelompok kerja APA diam-diam mengerjakan beberapa hal lain juga. Salah satunya adalah spesifikasi, awalnya dijuluki Web Forms 2.0 , yang menambahkan jenis kontrol baru ke formulir HTML. (Anda akan belajar lebih banyak tentang formulir web di A Form of Madness .) Yang lain adalah spesifikasi rancangan yang disebut "Aplikasi Web 1.0," yang mencakup fitur-fitur baru utama seperti kanvas gambar mode langsung dan dukungan asli untuk audio dan video tanpa plugin .

Pada Oktober 2009, W3C menutup Kelompok Kerja XHTML 2 dan mengeluarkan pernyataan ini untuk menjelaskan keputusan mereka :

Ketika W3C mengumumkan Kelompok Kerja HTML dan XHTML 2 pada bulan Maret 2007, kami mengindikasikan bahwa kami akan terus memantau pasar untuk XHTML 2. W3C mengakui pentingnya sinyal yang jelas kepada masyarakat tentang masa depan HTML.

Meskipun kami mengakui nilai kontribusi Kelompok Kerja XHTML 2 selama bertahun-tahun, setelah berdiskusi dengan para peserta, manajemen W3C telah memutuskan untuk mengizinkan piagam Kelompok Kerja berakhir pada akhir tahun 2009 dan tidak memperbaruinya.

Yang menang adalah yang mengirim.

— Srikar Doddi
sumber

12

Alasan saya bertanya adalah karena Anda tahu itu opsional untuk alasan kompatibilitas; dan mereka akan membuatnya (wajib | dilarang) jika mereka bisa.

Itu kesimpulan yang menarik. Bacaan saya tentang itu adalah bahwa setiap saat tag dapat disimpulkan dengan andal, tag adalah opsional. Desain menunjukkan bahwa tujuannya adalah membuatnya cepat dan mudah untuk ditulis.

Apa yang dilakukan HTML 1, 2, 3 terkait dengan tag penutup yang sekarang opsional ini.

DTD untuk HTML 2 tertanam di RFC yang, bersama dengan HTML DTD asli , memiliki tag awal dan akhir opsional di semua tempat.

HTML 3 ditinggalkan (berkat perang browser) dan diganti dengan HTML 3.2 (yang dirancang untuk menggambarkan keadaan web saat itu).

Apa yang dilakukan HTML 5?

HTML 5 diarahkan untuk "membuka jalan setapak" sejak awal.

Dan apa yang harus saya lakukan?

Ah, sekarang subjektif dan argumentatif :)

Beberapa orang berpikir bahwa tag eksplisit lebih baik untuk keterbacaan dan pemeliharaan karena berada di depan mata pembaca.

Beberapa orang berpikir bahwa tag yang disimpulkan lebih baik untuk keterbacaan dan pemeliharaan karena tidak mengacaukan editor.

— Quentin
sumber

1

+1 saya belum memikirkan gagasan "disimpulkan dengan andal". Jadi itu mendukung gagasan bahwa sebenarnya tidak ada niat apa pun. saya berasumsi bahwa spesifikasi tersebut berusaha agar serapat mungkin dengan konten HTML dan spesifikasi HTML yang ada.

— Ian Boyd

Maaf, Dave, saya memberikannya kepada aslum; dia membutuhkan perwakilan :) Tapi Anda memiliki ide yang sama, dengan lebih banyak konten yang tertaut dan dikutip. Tapi jawaban yang bagus.

— Ian Boyd

8

Apa yang dilakukan HTML 5?

Jawaban atas pertanyaan ini ada di W3C Working Draft: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

Dan apa yang harus saya lakukan?

Ini masalah gaya. Saya mencoba untuk tidak pernah menghilangkan tag akhir karena itu membantu saya untuk menjadi keras dan tidak menghilangkan tag yang diperlukan.

— ghoppe
sumber

+1 untuk tautan ke draf spesifikasi HTML 5, dan bagian yang sesuai. Tetapi html 5 tidak mengatakan apa pun.

— Ian Boyd

6

Jika berlebihan, tinggalkan saja.

Jika itu melayani tujuan (bahkan tujuan yang tampaknya sepele, seperti memenuhi tuntutan IDE Anda atau menenangkan mata Anda), biarkan saja.

Jarang dalam spesifikasi yang terdefinisi dengan baik untuk melihat item opsional yang tidak memengaruhi perilaku. Kecuali "komentar", tentu saja. Tetapi spesifikasi HTML kurang dari spesifikasi desain, dan lebih merupakan dokumen dari kondisi implementasi utama saat ini. Jadi ketika suatu item bersifat opsional dalam HTML dan tampaknya tidak ada gunanya, kita dapat menebak bahwa sifat opsional hanyalah dokumentasi dari kekhasan dalam browser tertentu.

Melihat bagian HTML-5 RFC spec yang ditautkan di atas, Anda melihat bahwa tag opsional secara aneh terkait dengan keberadaan komentar! Itu akan memberi tahu Anda bahwa penulis tidak mengenakan topi desain. Mereka malah memainkan permainan "mendokumentasikan kebiasaan" dalam implementasi besar. Jadi kita tidak bisa menganggap spek terlalu serius dalam hal ini.

Jadi, solusinya adalah: Jangan berkeringat. Pindah ke sesuatu yang benar-benar penting. :)

— John
sumber

5

Saya pikir jawaban terbaik adalah dengan memasukkan tag penutup untuk keterbacaan atau deteksi kesalahan. Namun, jika Anda memiliki banyak HTML yang dihasilkan (katakanlah, tabel data), Anda dapat menghemat bandwidth yang signifikan dengan menghilangkan tag opsional.

— Gabe
sumber

2

Richard: Ketika Anda memiliki struktur bersarang yang dalam, jauh lebih mudah bagi Anda untuk menemukan kesalahan karena tag penutup memberikan informasi lebih lanjut tentang maksud.

— Gabe

1

Saya pikir "tag penutup memberikan lebih banyak informasi tentang maksud" adalah jawaban singkat terbaik untuk pertanyaan ini. Mengargumentasikan alasan yang jelas dan bagus.

— squarecandy

4

Rekomendasi saya adalah Anda menghilangkan sebagian besar tag penutup opsional, dan semua atribut opsional yang dapat Anda hilangkan. Banyak IDE akan mengeluh sehingga Anda mungkin tidak bisa menghilangkan beberapa dari ini tetapi umumnya lebih baik untuk ukuran file yang lebih kecil dan lebih sedikit kekacauan. Jika Anda memiliki generator kode pasti menghilangkan tag akhir di sana karena Anda bisa mendapatkan beberapa pengurangan ukuran yang baik dari itu. Biasanya itu tidak terlalu penting.

Tetapi ketika itu penting, maka lakukanlah. Pada beberapa karya terbaru saya, saya dapat mengurangi ukuran HTML yang saya render dari 1,5 MB menjadi 800 KB dengan menghilangkan sebagian besar atribut yang dihasilkan akhir dan nilai redundan untuk tag terbuka, di mana teks elemen sama dengan nilai. Saya memiliki sekitar 200 tag. Saya bisa menerapkan ini dengan cara lain sepenuhnya, tetapi itu akan lebih banyak bekerja ($$$), jadi ini memungkinkan saya untuk dengan mudah membuat halaman lebih responsif.

Hanya karena penasaran saya menemukan bahwa jika saya menghapus tanda kutip di sekitar atribut yang tidak membutuhkannya saya bisa menghemat 20 KB, tetapi IDE saya (Visual Studio) tidak menyukainya. Saya juga terkejut menemukan bahwa ID yang sangat panjang yang dihasilkan oleh ASP.NET menghasilkan 20% dari file saya.

Gagasan bahwa kami bisa mendapatkan fraksi yang relevan dari HTML yang benar-benar valid ternyata salah arah, jadi lakukan apa pun yang terbaik untuk Anda dan pelanggan Anda. Sebagian besar alat yang pernah saya lihat atau gunakan akan mengatakan mereka menghasilkan xhtml, tetapi mereka tidak benar-benar bekerja 100%, dan bagaimanapun juga tidak ada manfaat dari kepatuhan yang ketat.

— pengguna1777246
sumber

Saya hampir tidak dapat menerima penghapusan tag-akhir opsional, tetapi saya menemukan ide yang buruk untuk menghilangkan tanda kutip pada atribut. Anda mempertaruhkan situs Anda untuk masuk ke beberapa browser dengan cara itu. Jika Anda memiliki file html 800kb, Anda melakukan sesuatu yang sangat salah.

— Christoph

2

@Christoph: Menghilangkan tag akhir opsional (suka </p>atau </li>) baik-baik saja sesuai dengan spesifikasi HTML. Jika browser tidak memahaminya, maka ada masalah dengan browser.

— Konrad Borowski

2

Secara pribadi, saya penggemar XHTML dan, seperti ghoppe, "Saya mencoba untuk tidak pernah menghilangkan tag akhir karena itu membantu saya untuk menjadi keras dan tidak menghilangkan tag yang diperlukan."

tapi

Jika Anda sengaja menggunakan HTML 4.n, orang tidak dapat membantah bahwa dengan menyertakannya membuatnya lebih mudah untuk mengkonsumsi dokumen, karena gagasan pembentukan yang baik sebagai lawan validitas adalah konsep XML, dan Anda kehilangan manfaat itu saat Anda melarang tag penutup tertentu. Jadi satu-satunya masalah menjadi validitas ... dan jika masih berlaku tanpa mereka ... Anda mungkin menghemat bandwidth, bukan?

— Richard JP Le Guen
sumber

2

Menggunakan tag akhir membuat berurusan dengan fragmen lebih mudah karena perilakunya tidak bergantung pada elemen saudara. Alasan ini saja harus cukup meyakinkan. Apakah ada yang berurusan dengan dokumen html monolitik lagi?

— CurtainDog
sumber

1

Dalam beberapa bahasa kurung kurawal seperti C #, Anda dapat menghilangkan kurung kurawal di sekitar pernyataan if jika panjangnya hanya dua baris. sebagai contoh...

if ([condition])
[code]

tetapi Anda tidak dapat melakukan ini ...

if ([kondisi])
[kode]
[kode]

baris ketiga tidak akan menjadi bagian dari pernyataan if. itu menyakitkan keterbacaan, dan bug dapat dengan mudah diperkenalkan, dan sulit ditemukan.

untuk alasan yang sama, saya menutup semua tag. tag seperti tag img masih perlu ditutup, hanya saja tidak dengan tag penutup yang terpisah.

— MiguelR
sumber

Bisakah Anda memberi contoh HTML yang sangat rumit? Dalam pengalaman saya, tag akhir opsional tidak terlalu menipu.

— Kornel

Saya ingat memiliki masalah dengan IE7 beberapa tahun yang lalu di mana saya menemukan tag pembuka pada baris terpisah dari teks yang terkandung di dalamnya, tanpa penutup li, IE7 memperlakukan semua peluru seperti satu peluru besar. menempatkan tag dan teks pada satu baris, atau menutup tag, akan menyelesaikan masalah. Saya sepertinya tidak bisa menegur ini sekarang, jadi mungkin juga ada hubungannya dengan css dalam permainan. tetapi saya tidak akan menyalahkan Anda karena menganggap ini sebagai "Saya benar-benar punya pacar ... di Kanada!" cerita.

— MiguelR

0

Jika Anda menulis parser HTML, apakah akan lebih mudah untuk mem-parsing HTML yang menyertakan tag penutup opsional, atau HTML yang tidak? Saya pikir tag penutup opsional yang hadir akan membuatnya lebih mudah, karena saya tidak perlu menyimpulkan di mana tag penutup seharusnya.

Untuk alasan itu, saya selalu menyertakan tag penutup opsional - pada teori bahwa halaman saya mungkin membuat lebih cepat, karena saya membuat lebih sedikit pekerjaan untuk parser HTML browser.

— Joel Mueller
sumber

1

Saya tidak setuju; gagasan tentang keteraturan sebagai kebalikan dari validitas adalah konsep hanya-XML dan menjadi tidak relevan ketika Anda memiliki elemen yang tag dekatnya dilarang .

— Richard JP Le Guen

1

Saya mengerti itu, tetapi elemen DOM yang diberikan memiliki awal dan akhir, bahkan jika tag HTML Anda tidak. Jika Anda menyertakan <li>tag tanpa tag penutup, pada titik tertentu browser harus memutuskan di mana elemen berakhir, dan bertindak seolah-olah Anda telah menempatkan tag akhir pada titik itu. Ini mungkin jumlah yang relatif sepele dari logika, tetapi "beberapa" masih lebih dari "tidak ada" dan saya pikir itu tidak masuk akal untuk menganggap bahwa meninggalkan tag akhir opsional membuat lebih banyak pekerjaan untuk browser daripada memasukkannya.

— Joel Mueller

Ini poin yang menarik tetapi saya masih tidak setuju; tag dekat adalah opsional karena mereka akan diperlukan dan dengan demikian implisit sesuai dengan aturan validasi ... jadi ketika parser mencapai titik di mana ada memiliki menjadi tag penutup menurut validasi, tidak bisa itu dikatakan bahwa tugas mengkonsumsi tag penutup (bila ada) hanya akan memperlambatnya?

— Richard JP Le Guen

@ Richard - Saya kira itu tergantung pada implementasi aktual di browser tertentu, tapi saya kesulitan mengkredit ide bahwa menjadi eksplisit tentang di mana Anda ingin elemen untuk berakhir akan lebih buruk untuk kinerja daripada memberitahu browser untuk mencari tahu kamu.

— Joel Mueller

@ RichardJPLeGuen Saya kira, itu semua tergantung pada bagaimana tepatnya aturannya. Ketika Anda menutup a </table>dan tumpukan Anda berisi <table><tbody><tr><td>, maka Anda bisa menutup semuanya sampai Anda cocok dengan <table>. Demikian pula untuk membuka <p>dalam konteks non-jam. Tapi mungkin ada banyak kasus yang lebih sulit, saya tidak tahu.

— maaartinus

-1

Lakukan apa pun yang menurut Anda membuat kode lebih mudah dibaca dan dipelihara.

Secara pribadi saya akan selalu cenderung untuk menutup <td>dan <tr>, tetapi saya tidak akan pernah peduli <li>.

— Matthew Wilson
sumber

1

Saya berharap untuk beberapa panduan atas keputusan desain asli, dan bahwa mereka akan melakukan x jika mereka bisa.

— Ian Boyd

Apa perbedaan antara <td>dan <li>itu yang membuat Anda tidak repot-repot <li>? Bagi saya, ada sedikit perbedaan.

— ghoppe

Tidak ada perbedaan teknis, itu murni subjektif. Saya merasa bisa membaca HTML dengan lebih baik jika saya menutup td dan tr. Tapi aku tidak pernah merasakan kebutuhan dengan li.

— Matthew Wilson

-2

Untuk jenis penutupan terlarang gunakan sintaksis seperti: <img />Dengan />untuk menutup tag yang diterima dalam xml

— Dani
sumber

1

Ini tidak berfungsi di HTML4 (cocok dengan sintaks SGML yang tidak jelas yang melakukan sesuatu yang sedikit berbeda). Di HTML5 diizinkan, tetapi tidak berarti.

— Kornel