Niektóre znaczniki zamykające HTML 1 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
1 HTML 4.01
</p>tagi zamykające , a drugi je pomija!/>, na przykład<meta charset="utf-8" />, chociaż<meta charset="utf-8">jest ważny HTML5?<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" /><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?Odpowiedzi:
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.
źródło
<LI>jest jak kula. Nikt nie chciałby zawijać całego wypunktowania<LI>...</LI>. W ten sposóbLIdopasowuje 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ą.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łędneul > uldrzewo.Ważny:
Nieważny:
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:
przeanalizuje jako:
Może pomóc tylko podczas sprawdzania poprawności dokumentów.
źródło
<p>foo <p>bar</p> baz</p>nie jest analizowany jako dwa zagnieżdżoneptagi?<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)”.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).<t>nie będzie działał<title>.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 :
źródło
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.
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).
HTML 5 od samego początku był nastawiony na „utorowanie krowich ścieżek”.
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.
źródło
Odpowiedź na to pytanie znajduje się w wersji roboczej W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
To kwestia stylu. Staram się nigdy nie pomijać tagów końcowych, ponieważ pomaga mi być rygorystycznym i nie pomijać niezbędnych tagów.
źródło
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. :)
źródło
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.
źródło
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.
źródło
</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ą.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?
źródło
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?
źródło
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.
źródło
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.
źródło
<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.</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.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>.źródło
<td>i<li>to sprawia, że nie zawracasz sobie głowy<li>? Dla mnie różnica jest niewielka.W przypadku niedozwolonych typów zamykania użyj składni takiej jak:
<img />With the,/>aby zamknąć tag, który jest akceptowany w xmlźródło