HTML: uwzględnić czy wykluczyć opcjonalne tagi zamykające?

149

Niektóre znaczniki zamykające HTML ¹ są opcjonalne , np .:

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

Uwaga: nie mylić z tagami zamykającymi, których nie wolno umieszczać, tj .:

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

Uwaga: xhtml różni się od HTML. xhtml to forma XML, która wymaga, aby każdy element miał tag zamykający. Tag zamykający może być zabroniony w html, ale obowiązkowy w xhtml.

Są opcjonalnymi tagami zamykającymi

najlepiej uwzględnione , ale zaakceptujemy je, jeśli o nich zapomnisz lub
najlepiej nie uwzględnione, ale zaakceptujemy je, jeśli je umieścisz

Innymi słowy, czy powinienem je uwzględniać, czy nie ?

Specyfikacja HTML 4.01 mówi o tym, że zamykanie tagów elementów jest opcjonalne , ale nie mówi, czy jest to preferowane, czy lepiej ich nie uwzględniać.

Z drugiej strony losowy artykuł na DevGuru mówi :

Tag końcowy jest opcjonalny. Jednak zaleca się, aby był dołączony.

Pytam, bo po prostu wiesz, że jest to opcjonalne ze względu na kompatybilność; i zrobiliby to ( obowiązkowe | zabronione ), gdyby mogli.

Mówiąc inaczej: co zrobił HTML 1, 2, 3 w odniesieniu do tych, teraz opcjonalnych, zamykających tagów. Co robi HTML 5? A co mam zrobić?

Uwaga

Niektóre elementy HTML są zabronione od konieczności zamykania tagi. Możesz się z tym nie zgodzić, ale taka jest specyfikacja i nie podlega dyskusji. Pytam o opcjonalne tagi zamykające i jaki był zamiar.

Przypisy

¹ HTML 4.01

html html4

— Ian Boyd
źródło

4

Trudne pytanie ... niektóre zalecenia w3c zawierają nawet przykłady, które robią obie te rzeczy: w3.org/TR/html401/struct/global.html#id-and-class Pierwszy przykład zawiera </p>tagi zamykające , a drugi je pomija!

— Richard JP Le Guen

Wystarczy, aby wyjaśnić - w przypadku niedozwolonych znaczników w HTML5, „jawna” / XML ważna rozwiązaniem jest zamknąć je z />, na przykład <meta charset="utf-8" />, chociaż <meta charset="utf-8">jest ważny HTML5?

— cboettig

@cboettig Yes. <meta charset="utf-8" />to nieprawidłowy html, to musi być <meta charset="utf-8">. Z drugiej strony <meta charset="tuf-8">jest nieprawidłowy xhtml, to musi być<meta charset="utf-8" />

— Ian Boyd

@IanBoyd naprawdę? w HTML5? Projekt instrukcja W3C dla poliglota html / xhtml mówi do korzystania <meta charset="UTF-8"/>z tagiem zamykającym. W przeciwnym razie w jaki sposób polyglot lub xhtml mógłby kiedykolwiek zweryfikować jako html5 i xml?

— cboettig

@cboettig Masz rację. Polyglot Markup (tj. Dokumenty XHTML zgodne z HTML ) nie może być poprawnym HTML 4.01. HTML5 (wciąż w toku) ma pojęcie elementów Void - elementów, które nie mogą mieć znacznika końcowego . Prawdopodobnie większość przeglądarek jest delikatna i wybacza błędy w znacznikach.

— Ian Boyd

49

Te opcjonalne to te, które powinny być semantycznie jasne, gdzie się kończą, bez konieczności stosowania tagu końcowego. EG każdy <li>implikuje a, </li>jeśli nie ma żadnego tuż przed nim.

Po wszystkich zabronionych znacznikach końcowych natychmiast następowałby ich znacznik końcowy, więc zbyteczne byłoby wpisywanie za <img src="blah" alt="blah"></img>każdym razem.

Prawie zawsze używam opcjonalnych tagów (chyba że mam bardzo dobry powód, aby tego nie robić), ponieważ nadają to bardziej czytelny i aktualizowalny kod.

— aslum
źródło

18

Teraz to widzę. <LI>jest jak kula. Nikt nie chciałby zawijać całego wypunktowania <LI>...</LI>. W ten sposób LIdopasowuje się to, co ludzie naturalnie napisaliby podczas znaczników. Sames wybiera znak akapitu ( <P>), w edytorze tekstu dodajesz znak akapitu na początku akapitu; i nie na końcu każdego też. Zatem w tej interpretacji znaczniki zamykające są opcjonalne, ponieważ żadna normalna osoba nie pomyślałaby o ich posiadaniu. Ponadto sam element nie ma treści - element jest treścią.

— Ian Boyd

8

Co masz na myśli przez prawie zawsze używać opcjonalnych tagów - to znaczy, że obejmują znacznik końcowy, albo że go pominąć ? (Odniosłem wrażenie, że to uwzględniasz , czytając twoją odpowiedź - ale powyższy komentarz Iana Boyda sprawia wrażenie, że go wykluczasz .)

— KajMagnus

3

@IanBoyd A co do ostatniego akapitu?

— Pacerier,

22

@Pacerier Ludzie piszą akapity tekstu od setek lat. Nikt nigdy nie był zdezorientowany, gdy kończy się akapit.

— Ian Boyd,

4

Odpowiedni link do HTML5, dla tych, którzy znaleźli tę odpowiedź, próbując znaleźć rzeczywistą dokumentację referencyjną: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

Są przypadki, w których pomocne są wyraźne tagi, ale czasami jest to niepotrzebna pedanteria.

Zwróć uwagę, że specyfikacja HTML jasno określa, kiedy można pomijać tagi, więc nie zawsze jest to błąd.

Na przykład nigdy nie potrzebujesz </body></html>. Nikt nigdy nie pamięta, żeby wyrazić to <tbody>wprost (do tego stopnia, że XHTML robił dla niego wyjątki).

Nie potrzebujesz, </head><body>chyba że masz skrypty manipulujące DOM, które faktycznie wyszukują <head>(wtedy lepiej zamknąć to jawnie, ponieważ reguły dla domniemanego końca <head>mogą cię zaskoczyć).

Listy zagnieżdżone są właściwie lepiej bez nich </li>, ponieważ wtedy trudniej jest stworzyć błędne ul > uldrzewo.

Ważny:

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

Nieważny:

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

Pamiętaj, że tagi końcowe są implikowane niezależnie od tego, czy próbujesz zamknąć wszystkie elementy, czy nie. Umieszczenie tagów końcowych nie spowoduje automatycznego zwiększenia niezawodności analizy:

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

przeanalizuje jako:

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

Może pomóc tylko podczas sprawdzania poprawności dokumentów.

— Kornel
źródło

4

Czekaj, dlaczego <p>foo <p>bar</p> baz</p>nie jest analizowany jako dwa zagnieżdżone ptagi?

— Eric

19

Ponieważ <P>element nie może zawierać elementów <P>blokowych i jest elementem blokowym. From ( w3.org/TR/REC-html40/struct/text.html#edef-P ) „Element P reprezentuje akapit. Nie może zawierać elementów blokowych (w tym samego P)”.

— Ian Boyd

1

@IanBoyd Czy masz na myśli to, że nie może zawierać elementów blokowych niezależnie od reguł CSS?

— Pacerier,

6

@Pacerier CSS nie może w żaden sposób wpływać na DOM. Najpierw analizowany jest DOM, a następnie CSS go wyświetla. blockWyświetlanie CSS to zupełnie inna rzecz niż zawartość blokowa HTML (po prostu zdarza się, że większość elementów blokowych HTML jest domyślnie wyświetlana jako bloki CSS).

— Kornel,

2

@ anton1980 Nie, to nie to samo. Obsługa pominiętych opcjonalnych tagów zamykających jest jasno określona i działa niezawodnie we wszystkich zgodnych przeglądarkach. OTOH makijaż <t>nie będzie działał <title>.

— Kornel

18

Dodam tutaj kilka linków, które pomogą Ci zapoznać się z historią HTML, abyś mógł zrozumieć różne sprzeczności. To nie jest odpowiedź na twoje pytanie, ale po przeczytaniu tych różnych podsumowań dowiesz się więcej.

Niektóre fragmenty z Dive Into HTML5 :

Fakt, że „zepsute” znaczniki HTML nadal działały w przeglądarkach internetowych, skłonił autorów do tworzenia uszkodzonych stron HTML. Wiele zepsutych stron. Według niektórych szacunków ponad 99% stron HTML w Internecie ma obecnie co najmniej jeden błąd. Ale ponieważ te błędy nie powodują, że przeglądarki wyświetlają widoczne komunikaty o błędach, nikt nigdy ich nie naprawia.

W3C uznało to za podstawowy problem w sieci i postanowili go naprawić. XML, opublikowany w 1997 roku, zerwał z tradycją wybaczania klientom i nakazał wszystkim programom, które używają XML, traktować tak zwane błędy „prawidłowości” jako fatalne. Ta koncepcja niepowodzenia przy pierwszym błędzie stała się znana jako „drakońska obsługa błędów” od nazwiska greckiego przywódcy Draco, który nałożył karę śmierci za stosunkowo drobne naruszenia jego prawa. Kiedy W3C przeformułowało HTML jako słownik XML, nakazali, aby wszystkie dokumenty obsługiwane z nowym application/xhtml+xmltypem MIME podlegały drakońskiej obsłudze błędów. Gdyby na Twojej stronie XHTML wystąpił choćby jeden poprawnie sformułowany błąd, […] przeglądarki internetowe nie miałyby innego wyjścia, jak zatrzymać przetwarzanie i wyświetlić komunikat o błędzie użytkownikowi końcowemu.

Pomysł ten nie był powszechnie popularny. Przy szacowanym poziomie błędów na poziomie 99% na istniejących stronach, nieustannie występującej możliwości wyświetlania błędów użytkownikowi końcowemu oraz braku nowych funkcji w XHTML 1.0 i 1.1 uzasadniających koszty, autorzy stron internetowych w zasadzie zignorowali application/xhtml+xml. Ale to nie znaczy, że całkowicie zignorowali XHTML. Och, zdecydowanie nie. Dodatek C do specyfikacji XHTML 1.0 dał autorom stron internetowych na całym świecie lukę: „Użyj czegoś, co wygląda trochę jak składnia XHTML, ale nadal używaj tego typu text/htmlMIME”. I to jest dokładnie to, co zrobiły tysiące programistów internetowych: „zaktualizowali” składnię do XHTML, ale nadal obsługują ją z typem MIME text / html.

Nawet dzisiaj miliony stron internetowych podają się za XHTML. Zaczynają od typu dokumentu XHTML w pierwszym wierszu, używają nazw znaczników pisanych małymi literami, używają cudzysłowów wokół wartości atrybutów i dodają ukośnik na końcu pustych elementów, takich jak <br />i <hr />. Ale tylko niewielka część tych stron jest obsługiwana z application/xhtml+xmltypem MIME, który spowodowałby drakońską obsługę błędów XML. Każda strona udostępniana z typem MIME text/html- niezależnie od typu dokumentu, składni czy stylu kodowania - zostanie przeanalizowana przy użyciu „wybaczającego” parsera HTML, dyskretnie ignorującego wszelkie błędy w znacznikach i nigdy nie ostrzegającego użytkowników końcowych (ani nikogo innego), nawet jeśli strony są zepsute technicznie.

XHTML 1.0 zawierał tę lukę, ale XHTML 1.1 ją zamknął, a nigdy nieukończony XHTML 2.0 kontynuował tradycję wymagania drakońskiej obsługi błędów. I właśnie dlatego istnieją miliardy stron, które podają się za XHTML 1.0 i tylko kilka, które podają się za XHTML 1.1 (lub XHTML 2.0). Więc czy naprawdę używasz XHTML? Sprawdź swój typ MIME. (Właściwie, jeśli nie wiesz, jakiego typu MIME używasz, mogę zagwarantować, że nadal używasz text/html.) Chyba że obsługujesz swoje strony za pomocą typu MIME application/xhtml+xml, tak zwanego „XHTML” to XML tylko z nazwy.

Osoby, które zaproponowały ewolucję formularzy HTML i HTML, stanęły przed dwoma wyborami: zrezygnować lub kontynuować pracę poza W3C. Wybrali to drugie, zarejestrowali whatwg.orgdomenę, aw czerwcu 2004 roku narodziła się grupa robocza WHAT .

Grupa robocza [T] ON WHAT też po cichu pracowała nad kilkoma innymi sprawami. Jedną z nich była specyfikacja, początkowo nazwana Web Forms 2.0 , która dodawała nowe typy kontrolek do formularzy HTML. (Dowiesz się więcej o formularzach internetowych w A Form of Madness ). Inną była szkic specyfikacji o nazwie „Aplikacje internetowe 1.0”, która zawierała główne nowe funkcje, takie jak płótno do rysowania w trybie bezpośrednim oraz natywne wsparcie dla audio i wideo bez wtyczek .

W październiku 2009 roku W3C zamknął grupę roboczą XHTML 2 i wydał następujące oświadczenie, aby wyjaśnić swoją decyzję :

Kiedy W3C ogłosiło utworzenie grup roboczych HTML i XHTML 2 w marcu 2007 roku, wskazaliśmy, że będziemy nadal monitorować rynek XHTML 2. W3C uznaje znaczenie jasnego sygnału dla społeczności na temat przyszłości HTML.

Chociaż doceniamy wartość wkładu Grupy Roboczej XHTML 2 przez lata, po dyskusji z uczestnikami, kierownictwo W3C zdecydowało, że statut Grupy Roboczej wygaśnie z końcem 2009 roku i nie będzie go odnawiać.

Te, które wygrywają, to te, które wysyłają.

— Srikar Doddi
źródło

12

Pytam tylko dlatego, że wiesz, że jest to opcjonalne ze względu na kompatybilność; i zrobiliby to (obowiązkowe | zabronione), gdyby mogli.

To ciekawy wniosek. Czytam o tym, że prawie za każdym razem, gdy można wiarygodnie wywnioskować tag, tag jest opcjonalny. Projekt sugeruje, że chodziło o to, aby pisać szybko i łatwo.

Co zrobił HTML 1, 2, 3 w odniesieniu do tych, teraz opcjonalnych, zamykających tagów.

DTD dla HTML 2 jest osadzone w dokumencie RFC, który wraz z oryginalnym DTD HTML zawiera opcjonalne znaczniki początku i końca w każdym miejscu.

HTML 3 został porzucony (dzięki wojnom przeglądarkowym) i zastąpiony HTML 3.2 (który miał opisywać ówczesny stan sieci).

Co robi HTML 5?

HTML 5 od samego początku był nastawiony na „utorowanie krowich ścieżek”.

I co powinienem zrobić?

Ach, teraz to jest subiektywne i dyskusyjne :)

Niektórzy uważają, że wyraźne tagi są lepsze dla czytelności i łatwości konserwacji, ponieważ znajdują się przed oczami czytelnika.

Niektórzy uważają, że wywnioskowane tagi są lepsze pod względem czytelności i łatwości konserwacji, ponieważ nie zaśmiecają edytora.

— Quentin
źródło

1

+1 Nie przyszło mi do głowy pojęcie „wiarygodnie wywnioskowane”. To popiera ideę, że tak czy inaczej nie było żadnego zamiaru. Zakładałem, że specyfikacja starała się być jak najbardziej zgodna z istniejącą treścią HTML i specyfikacjami HTML.

— Ian Boyd

Przepraszam, Dave, oddałem go do aslum; potrzebuje przedstawiciela :) Ale masz ten sam pomysł, z większą liczbą linków i cytowanych treści. Ale dobra odpowiedź.

— Ian Boyd

8

Co robi HTML 5?

Odpowiedź na to pytanie znajduje się w wersji roboczej W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

I co powinienem zrobić?

To kwestia stylu. Staram się nigdy nie pomijać tagów końcowych, ponieważ pomaga mi być rygorystycznym i nie pomijać niezbędnych tagów.

— ghoppe
źródło

+1 dla linku do wersji roboczej specyfikacji HTML 5 i odpowiedniej sekcji. Ale html 5 nie mówi tego ani w inny sposób.

— Ian Boyd

6

Jeśli jest zbyteczna, pomiń ją.

Jeśli służy celowi (nawet pozornie banalnemu celowi, na przykład uspokojeniu IDE lub uspokojeniu oczu), zostaw to.

W dobrze zdefiniowanej specyfikacji rzadko można zobaczyć opcjonalne elementy, które nie wpływają na zachowanie. Oczywiście z wyjątkiem „komentarzy”. Ale specyfikacja HTML jest mniej specyfikacją projektową, a bardziej dokumentem stanu obecnych głównych implementacji. Więc kiedy pozycja jest opcjonalna w HTML i wydaje się bezcelowa, możemy zgadywać, że opcjonalna natura jest jedynie dokumentacją dziwactwa w określonej przeglądarce.

Patrząc na sekcję specyfikacji RFC HTML-5, do której link znajduje się powyżej, widać, że opcjonalne tagi są dziwnie powiązane z obecnością komentarzy! To powinno ci powiedzieć, że autorzy nie noszą designerskich kapeluszy. Zamiast tego grają w grę polegającą na „udokumentowaniu dziwactw” w głównych implementacjach. Nie możemy więc traktować specyfikacji zbyt poważnie w tym względzie.

Tak więc rozwiązanie brzmi: nie przejmuj się. Przejdź do czegoś, co naprawdę ma znaczenie. :)

— Jan
źródło

5

Myślę, że najlepszą odpowiedzią jest dodanie tagów zamykających w celu zwiększenia czytelności lub wykrywania błędów. Jeśli jednak masz dużo wygenerowanego kodu HTML (powiedzmy, tabele danych), możesz zaoszczędzić znaczną przepustowość, pomijając opcjonalne znaczniki.

— Gabe
źródło

2

Richard: Kiedy masz głęboko zagnieżdżone struktury, znacznie łatwiej jest znaleźć błędy, ponieważ znaczniki zamykające zawierają więcej informacji o intencji.

— Gabe

1

Myślę, że „zamykające tagi dają więcej informacji o zamiarze” to najlepsza zwięzła odpowiedź na to pytanie. Argumentuje dobry, jasny powód w taki czy inny sposób.

— squarecandy

4

Zalecam pominięcie większości opcjonalnych tagów zamykających i wszystkich opcjonalnych atrybutów, które mogą Ci ujść na sucho. Wiele środowisk IDE będzie narzekać, więc pominięcie niektórych z nich może nie być możliwe, ale generalnie jest to lepsze w przypadku mniejszego rozmiaru pliku i mniejszego bałaganu. Jeśli masz generatory kodu, zdecydowanie pomiń tam znaczniki końcowe, ponieważ możesz uzyskać z niego dobre zmniejszenie rozmiaru. Zwykle nie ma to znaczenia w taki czy inny sposób.

Ale kiedy ma to znaczenie, działaj zgodnie z tym. Podczas niektórych moich ostatnich prac udało mi się zmniejszyć rozmiar renderowanego kodu HTML z 1,5 MB do 800 KB, eliminując większość wygenerowanych atrybutów end i redundant value dla otwartego tagu, gdzie tekst elementu był taki sam jak wartość. Mam około 200 tagów. Mógłbym zaimplementować to całkowicie w inny sposób, ale wymagałoby to więcej pracy ($$$), dzięki czemu mogę łatwo zwiększyć responsywność strony.

Z ciekawości stwierdziłem, że jeśli usunę cudzysłowy wokół atrybutów, które ich nie potrzebują, mogę zaoszczędzić 20 KB, ale moje IDE (Visual Studio) tego nie lubi. Zaskoczyło mnie również, że naprawdę długi identyfikator generowany przez ASP.NET stanowi 20% mojego pliku.

Pomysł, że moglibyśmy kiedykolwiek uzyskać jakąkolwiek istotną część kodu HTML, który byłby ściśle poprawny, był w pierwszej kolejności błędny, więc zrób wszystko, co działa najlepiej dla Ciebie i Twoich klientów. Większość narzędzi, które kiedykolwiek widziałem lub używałem, powie, że generuje xhtml, ale tak naprawdę nie działają one w 100%, a ścisłe przestrzeganie nie przynosi żadnych korzyści.

— user1777246
źródło

Trudno mi zaakceptować pomijanie opcjonalnych znaczników końcowych, ale uważam, że pomijanie cudzysłowów w atrybutach jest raczej złym pomysłem. W ten sposób ryzykujesz, że Twoja witryna włamie się do niektórych przeglądarek. Jeśli masz 800kb plików html, robisz coś bardzo złego.

— Christoph

2

@Christoph: Pomijanie opcjonalnych tagów końcowych (takich jak </p>lub </li>) jest całkowicie w porządku zgodnie ze specyfikacją HTML. Jeśli przeglądarka tego nie rozumie, oznacza to problem z przeglądarką.

— Konrad Borowski

2

Osobiście jestem fanem XHTML i, podobnie jak ghoppe, „staram się nigdy nie pomijać tagów końcowych, ponieważ pomaga mi to być rygorystycznym i nie pomijać niezbędnych tagów”.

ale

Jeśli celowo używasz HTML 4.n, nie można argumentować, że włączenie ich ułatwia konsumowanie dokumentu, ponieważ pojęcie poprawnego sformułowania w przeciwieństwie do poprawności jest pojęciem XML i tracisz tę korzyść, gdy zabronić niektórych bliskich tagów. Więc jedynym problemem staje się ważność ... a jeśli nadal jest ważna bez nich ... równie dobrze możesz zaoszczędzić przepustowość, nie?

— Richard JP Le Guen
źródło

2

Używanie znaczników końcowych ułatwia obsługę fragmentów, ponieważ ich zachowanie nie jest zależne od elementów rodzeństwa. Już sam ten powód powinien być wystarczająco przekonujący. Czy ktoś ma już do czynienia z monolitycznymi dokumentami html?

— CurtainDog
źródło

1

W niektórych językach z nawiasami klamrowymi, takich jak C #, można pominąć nawiasy klamrowe wokół instrukcji if, jeśli ma ona tylko dwa wiersze. na przykład...

if ([stan])
[kod]

ale nie możesz tego zrobić ...

if ([warunek])
[kod]
[kod]

trzecia linia nie będzie częścią instrukcji if. szkodzi czytelności, a błędy można łatwo wprowadzić i być trudne do znalezienia.

z tych samych powodów zamykam wszystkie tagi. tagi takie jak img nadal muszą być zamknięte, ale nie oddzielnym tagiem zamykającym.

— MiguelR
źródło

Czy możesz podać przykład HTML, który jest tak skomplikowany? Z mojego doświadczenia wynika, że opcjonalne znaczniki końcowe nie są tak zwodnicze.

— Kornel

Pamiętam, że miałem problem z IE7 kilka lat temu, gdzie znalazłem otwierający li tag w oddzielnym wierszu od zawartego w nim tekstu, bez zamykającego li, IE7 traktował wszystkie kule jak jeden duży pocisk. umieszczenie tagu i tekstu w jednej linii lub zamknięcie tagu rozwiązałoby problem. Nie mogę jednak teraz tego powtórzyć, więc prawdopodobnie miało to również coś wspólnego z CSS w grze. ale nie winiłbym cię za to, że traktujesz to jako „mam dziewczynę ... w Kanadzie! fabuła.

— MiguelR

0

Gdybyś pisał parser HTML, czy byłoby łatwiej przeanalizować kod HTML zawierający opcjonalne znaczniki zamykające, czy kod HTML, który ich nie zawiera? Myślę, że obecność opcjonalnych tagów zamykających ułatwiłaby to, ponieważ nie musiałbym wnioskować, gdzie powinien być tag zamykający.

Z tego powodu zawsze dołączam opcjonalne znaczniki zamykające - zgodnie z teorią, że moja strona może renderować się szybciej, ponieważ tworzę mniej pracy dla parsera HTML przeglądarki.

— Joel Mueller
źródło

1

Nie zgadzam się; pojęcie poprawności w przeciwieństwie do poprawności jest pojęciem opartym tylko na XML i staje się nieistotne, gdy masz elementy, których zamknięte tagi są zabronione .

— Richard JP Le Guen

1

Rozumiem to, ale wyrenderowany element DOM ma zarówno początek, jak i koniec, nawet jeśli Twój tag HTML nie ma. Jeśli dołączysz <li>znacznik bez zamykającego znacznika, w pewnym momencie przeglądarka będzie musiała zdecydować, gdzie kończy się element i zachowywać się tak, jakbyś umieścił w tym miejscu znacznik końcowy. Może to być stosunkowo trywialna logika, ale „niektóre” to nadal więcej niż „brak” i nie sądzę, aby nierozsądne byłoby przypuszczać, że pominięcie opcjonalnych tagów końcowych wymaga więcej pracy dla przeglądarki niż ich włączenie.

— Joel Mueller

To interesująca kwestia, ale nadal się nie zgadzam; tagi zamykające są opcjonalne, ponieważ byłyby wymagane, a zatem niejawne zgodnie z regułami walidacji ... więc kiedy parser osiągnie punkt, w którym musi być tag zamykający zgodnie z walidacją, czy nie można argumentować, że zadanie konsumowania tag zamykający (jeśli jest obecny) po prostu spowolniłby to?

— Richard JP Le Guen

@Richard - Myślę, że zależy to od rzeczywistej implementacji w konkretnej przeglądarce, ale trudno mi przypisać pomysł, że wyraźne określenie, gdzie chcesz zakończyć element, byłoby gorsze dla wydajności niż nakazanie przeglądarce, aby to rozgryzła ty.

— Joel Mueller

@RichardJPLeGuen Myślę, że wszystko zależy od tego, jak dokładnie wyglądają zasady. Kiedy zamykasz a, </table>a twój stos zawiera <table><tbody><tr><td>, możesz po prostu zamknąć wszystko, aż dopasujesz <table>. Podobnie do otwierania <p>w kontekście innym niż zegar. Ale mogą być znacznie trudniejsze przypadki, nie wiem.

— maaartinus

-1

Rób wszystko, co uważasz, że kod jest bardziej czytelny i łatwiejszy w utrzymaniu.

Osobiście zawsze byłbym skłonny zamknąć <td>i <tr>, ale nigdy bym się tym nie przejmował <li>.

— Matthew Wilson
źródło

1

Liczyłem na jakieś wskazówki dotyczące pierwotnej decyzji projektowej i że zrobiliby x, gdyby mogli.

— Ian Boyd

Jaka jest różnica między <td>i <li>to sprawia, że nie zawracasz sobie głowy <li>? Dla mnie różnica jest niewielka.

— ghoppe

Nie ma różnicy technicznej, jest to czysto subiektywne. Czuję, że lepiej czytam HTML, jeśli zamknę td i tr. Ale nigdy nie czułem takiej potrzeby w przypadku li.

— Matthew Wilson,

-2

W przypadku niedozwolonych typów zamykania użyj składni takiej jak: <img />With the, />aby zamknąć tag, który jest akceptowany w xml

— Dani
źródło

1

Nie działa w HTML4 (pasuje do niejasnej składni SGML, która robi coś nieco innego). W HTML5 jest to dozwolone, ale bez znaczenia.

— Kornel