Jakie są wszystkie prawidłowe samozamykające się elementy w XHTML (zaimplementowane przez główne przeglądarki)?

188

Jakie są wszystkie prawidłowe elementy samozamykające (np. <br/>) w XHTML (zaimplementowane przez główne przeglądarki)?

Wiem, że technicznie XHTML pozwala na samozamykanie dowolnego elementu, ale szukam listy tych elementów obsługiwanych przez wszystkie główne przeglądarki. Zobacz http://dusan.fora.si/blog/self-closing-tags, aby zapoznać się z przykładami niektórych problemów spowodowanych przez samozamykające się elementy, takie jak <div />.

kamens
źródło
7
Czy to nie jest domyślnym celem XHTML? Pomyślałem, że jedną z zalet XHTML jest to, że można użyć generatora XML do generowania HTML. Dlaczego jakikolwiek generator XML miałby wiedzieć, które tagi mogą być samozamykające? Zbyt dziwne.
Elijah
6
Powodem, dla którego „kiepska”, „niepoprawna” odpowiedź została przyjęta, jest odpowiedź na pytanie, które ewidentnie zadawał kamens. Chciał wiedzieć, które elementy mogą zostać samozamykane podczas obsługi XHTML jako text / html bez powodowania problemów z renderowaniem w przeglądarkach. Wiele stron jest napisanych w XHTML i podawanych jako text / html, mimo że jest to technicznie niepoprawne. Pytanie można poprawić dzięki temu wyjaśnieniu, ale udzielenie odpowiedzi na inne pytanie (co się dzieje, gdy służysz jako application / xml lub czy pojedyncze tagi w tekście / html powinny mieć zamykające /) nie jest pomocne w tym przypadku.
Nick Lockwood,

Odpowiedzi:

179

Każda przeglądarka obsługująca XHTML (Firefox, Opera, Safari, IE9 ) obsługuje samozamykającą się składnię każdego elementu .

<div/>, <script/>, <br></br>Wszystko powinno działać dobrze. Jeśli tak nie jest, masz HTML z nieprawidłowo dodanym XHTML DOCTYPE.

DOCTYPE nie zmienia sposobu interpretacji dokumentu. Tylko typ MIME tak .

Decyzja W3C o ignorowaniu DOCTYPE :

Grupa robocza ds. HTML omówiła ten problem: zamiarem było umożliwienie starym przeglądarkom (obsługującym tylko HTML) akceptowanie dokumentów XHTML 1.0 zgodnie z wytycznymi i udostępnianie ich jako tekst / html. Dlatego dokumenty podawane jako tekst / html powinny być traktowane jako HTML, a nie jako XHTML.

To bardzo powszechna pułapka, ponieważ W3C Validator w dużej mierze ignoruje tę zasadę, ale przeglądarki przestrzegają jej religijnie. Przeczytaj artykuł Understanding HTML, XML i XHTML z bloga WebKit:

W rzeczywistości zdecydowana większość rzekomo XHTML dokumentów w Internecie jest obsługiwana jako text/html. Co oznacza, że ​​nie są w ogóle XHTML, ale w rzeczywistości nieprawidłowym HTML, który radzi sobie z obsługą błędów parserów HTML. Wszystkie te „Valid XHTML 1.0!” linki w sieci naprawdę mówią „Nieprawidłowy HTML 4.01!”.


Aby sprawdzić, czy masz prawdziwy XHTML lub nieprawidłowy HTML z DOCTYPE XHTML, umieść to w swoim dokumencie:

<span style="color:green"><span style="color:red"/> 
 If it's red, it's HTML. Green is XHTML.
</span>

Sprawdza, aw prawdziwym XHTML działa doskonale (zobacz: 1 vs 2 ). Jeśli nie możesz uwierzyć własnym oczom (lub nie wiesz, jak ustawić typy MIME), otwórz swoją stronę przez serwer proxy XHTML .

Innym sposobem sprawdzenia jest wyświetlenie źródła w przeglądarce Firefox. Podświetli ukośniki na czerwono, gdy są nieprawidłowe.

W HTML5 / XHTML5 to się nie zmieniło, a różnica jest jeszcze wyraźniejsza, ponieważ nie masz nawet dodatkowych DOCTYPE. Content-Typejest królem.


Dla przypomnienia, specyfikacja XHTML pozwala na samozamykanie dowolnego elementu poprzez uczynienie XHTML aplikacji XML : [wyróżnienie moje]

Znaczniki pustego elementu mogą być używane dla dowolnego elementu, który nie ma treści , niezależnie od tego, czy został zadeklarowany przy użyciu słowa kluczowego EMPTY.

Jest to również wyraźnie pokazane w specyfikacji XHTML :

Puste elementy muszą albo posiadać znacznik końcowy lub znacznik początkowy musi kończyć się />. Na przykład <br/>lub<hr></hr>

Kornel
źródło
7
Niepoprawny afaik, ponieważ użycie samozamykających się wersji <script>lub <div>powoduje różne renderowanie / interpretację.
ZeissS
13
@ZeissS tylko w text/html. W prawdziwym XHTML, wysłany tak application/xhtml+xml, jak działa dobrze. Przeczytaj artykuł, do którego mam łącze (lub specyfikację XHTML dodatek C) przed głosowaniem.
Kornel
3
@pornel Czy możesz zagwarantować, że samozamykające się tagi <script /> będą działać w starszych przeglądarkach? Nie sądzę. Brzmisz autorytatywnie, a większość twoich informacji jest dokładna, ale doświadczenie podpowiada mi, że samozamykające się tagi skryptów będą problematyczne i najlepiej jest po prostu ich całkowicie unikać, zamiast przyprawiać się o ból głowy.
Metagrapher,
6
@Metagrapher, jeśli starsze przeglądarki nie obsługują prawdziwego XHTML, LUB nie ustawisz typu MIME , to nie zadziała. Jednak w przeglądarkach obsługujących XHTML (wszystkie główne w tym momencie) z application/xhtml+xmltypem MIME mogę zagwarantować, że <script/>zadziała. Z typem MIME. Tylko.
Kornel
4
@capdragon: Starsze przeglądarki nie obsługują XHTML (wyświetlane jako „application / xhtml + xml”). Jeśli wyślesz im dokument XHTML jako „tekst / html”, wówczas XHTML zostanie wyrenderowany jako zupa tagów (tj. Przeglądarka przetwarza go jako HTML i rozważa błędy samozamykających się tagów, z których wdzięcznie odzyskuje). Masz opcje: 1. napisz HTML 4 (nie do końca opcja jeśli używasz ASP.NET, który renderuje XHTML), 2. serwuj XHTML jako „application / xhtml + xml” (wymaga IE9 +, a ten typ MIME zepsuje skrypty we wszystkich przeglądarkach tak czy owak, więc definitywnie nie ma takiej opcji), 3. napisz HTML 5, co w zasadzie sprawia, że ​​tag soup jest standardem :)
Triynko
41

Jednym z elementów, z którymi należy być bardzo ostrożnym w tym temacie, jest <scriptelement>. Jeśli masz zewnętrzny plik źródłowy, spowoduje to problemy podczas samodzielnego zamykania. Spróbuj:

<!-- this will not consistently work in all browsers! -->
<script type="text/javascript" src="external.js" />

To zadziała w Firefoksie, ale psuje się przynajmniej w IE6. Wiem, bo wpadłem na to, nadgorliwie samozamykając każdy element, który zobaczyłem ;-)

Erik van Brakel
źródło
Dotyczy wszystkich wersji MSIE: webbugtrack.blogspot.com/2007/08/…
scunliffe
4
<script> nie zamyka się samoczynnie w przeglądarce Firefox 3.
hsivonen
Cóż, działało w Firefoksie, kiedy go spotkałem. Wygląda na to, że nie działa już w żadnej przeglądarce. Może też może działać tylko w trybie dziwactw?
Erik van Brakel
1
@erickson działa dobrze w Firefoksie, jeśli masz właściwy typ MIME.
Kornel
WebKit nadal to robi ze względu na kompatybilność.
Yuhong Bao
35

Składnia samozamykająca działa na wszystkich elementach w application / xhtml + xml. Nie jest obsługiwany w żadnym elemencie w tekście / html, ale elementy, które są „puste” w HTML4 lub „void” w HTML5 i tak nie przyjmują tagu końcowego, więc jeśli umieścisz na nich ukośnik, wygląda to tak, jakby obsługiwana była samozamykająca się składnia.

hsivonen
źródło
33

Ze strony referencyjnej W3 Schools :

<area />
<base />
<basefont />
<br />
<hr />
<input />
<img />
<link />
<meta />
Conroy P.
źródło
7
w3schools.com/tags/default.asp Widzę 12 tagów kończących się na />:"area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "link", "meta", "param"
mpen
94
Należy pamiętać, że W3schools nie jest powiązany z W3C, a nawet nie odpowiada na poprawki przesłane przez członków W3C.
Kornel
2
Jak to często bywa, w3schools ma prawie rację. Dokładnym sposobem na znalezienie pustych elementów jest bieganie grep EMPTY xhtml1-strict.dtd | sortlubgrep EMPTY xhtml1-transitional.dtd | sort
cayhorstmann
2
IMHO, ludzie zbyt mocno walą w W3Schools. Okazało się, że jest świetnym źródłem informacji na początek (!) W temacie, o którym nic nie wiesz.
Priidu Neemre
28

Lepszym pytaniem byłoby: jakie tagi można samozamykać nawet w trybie HTML bez wpływu na kod? Odpowiedź: tylko te, które mają pustą treść (są nieważne). Zgodnie ze specyfikacją HTML następujące elementy są nieważne:

area, base, br, col, embed, hr, img, input, keygen, link, menuitem, meta, param, source, track, wbr

Podano również starszą wersję specyfikacji command. Poza tym, według różnych źródeł, następujące nieaktualne lub niestandardowe tagi są nieważne:

basefont, bgsound, frame, isindex

Dmitrij Osinovskiy
źródło
10

Mam nadzieję, że to komuś pomoże:

<base />
<basefont />
<frame />
<link />
<meta />

<area />
<br />
<col />
<hr />
<img />
<input />
<param />
Jeff
źródło
5

A co z <meta>i <link>? Dlaczego nie ma ich na tej liście?

Praktyczna zasada, nie zamykaj samoczynnie żadnego elementu, który ma mieć treść, ponieważ z pewnością wcześniej czy później spowoduje to problemy z przeglądarką.

Te, które z natury zamykają się samoczynnie, jak <br>i <img>, powinny być oczywiste. Te, które nie są ... po prostu ich nie zamykaj!

AmbroseChapel
źródło
4

Kiedy ostatnio sprawdzałem, następujące elementy były puste / void wymienione w HTML5.

Obowiązuje dla autorów: area, base, br, col, command, embed, eventsource, hr, img, input, link, meta, param, source

Nieprawidłowe dla autorów: basefont, bgsound, frame, spacer, wbr

Poza kilkoma nowościami w HTML5, powinno to dać ci wyobrażenie o tych, które mogą być obsługiwane podczas obsługi XHTML jako text / html. (Po prostu przetestuj je, sprawdzając wyprodukowany DOM).

Jeśli chodzi o XHTML obsługiwany jako application / xhtml + xml (co sprawia, że ​​jest to XML), obowiązują reguły XML i każdy element może być pusty (nawet jeśli XHTML DTD nie może tego wyrazić).

Cień2531
źródło
4

Powinieneś rzucić okiem na DTD xHTML , wszystkie są wymienione. Oto krótki przegląd wszystkich głównych:

<br />
<hr />
<img />
<input />
e-satis
źródło
1
Naprawiono i wyczyszczono znaczniki. Ostrożnie z linkami na tych stronach, wolno się ładują.
e-satis
4

W HTML 5 nazywane są elementami „void”. Są one wymienione w oficjalnej specyfikacji W3 .

Element void to element, którego model treści nigdy nie pozwala na posiadanie zawartości w żadnych okolicznościach.

Od kwietnia 2013 r. Są to:

area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track, wbr

Od grudnia 2018 r. (HTML 5.2) są to:

area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr

mpen
źródło
2

Innym problemem dotyczącym samozamykających się tagów w IE jest element tytułu. Kiedy IE (właśnie wypróbowałem to w IE7) widzi to, wyświetla użytkownikowi pustą stronę. Jednak „przeglądasz źródło” i wszystko tam jest.

<title/>

Pierwotnie widziałem to, kiedy mój XSLT wygenerował samozamykający się tag.

Kevin Hakanson
źródło
Chromium też nie lubi <title/>tagów.
uınbɐɥs
2

Nie będę się nad tym rozwodził, zwłaszcza że większość stron, które piszę, jest generowana lub tag zawiera treść. Jedyne dwa, które sprawiły mi kłopoty przy ich samozamykaniu, to:

<title/>

W tym celu po prostu uciekałem się do nadawania mu oddzielnego tagu zamykającego, ponieważ gdy już znajdzie się w tagu, <head></head>tak naprawdę nie powoduje to bałaganu w kodzie.

<script/>

Jest to duży problem, z którym ostatnio miałem problemy. Od lat zawsze używałem samozamykających się <script/>tagów, gdy skrypt pochodzi z zewnętrznego źródła. Ale bardzo niedawno zacząłem otrzymywać komunikaty o błędach JavaScript dotyczące formularza pustego. Po kilku dniach poszukiwań odkryłem, że problem polegał (podobno) na tym, że przeglądarka nigdy nie docierała do <form>tagu, ponieważ nie zdawała sobie sprawy, że to koniec <script/>tagu. Więc kiedy stworzyłem osobne <script></script>tagi, wszystko działało. Dlaczego różni się na różnych stronach, które stworzyłem w tej samej przeglądarce, nie wiem, ale znalezienie rozwiązania było wielką ulgą!

Nathan Sokalski
źródło