Dlaczego elementy samozamykającego skryptu nie działają?

Z jakiego powodu przeglądarki nie rozpoznają poprawnie:

<script src="foobar.js" /> <!-- self-closing script element -->

Tylko to jest rozpoznawane:

<script src="foobar.js"></script>

Czy to łamie koncepcję obsługi XHTML?

Uwaga: To stwierdzenie jest poprawne przynajmniej dla wszystkich IE (6-8 beta 2).

Specyfikacja XHTML 1 mówi:

С.3. Minimalizacja elementu i pusta zawartość elementu

Biorąc pod uwagę pustą instancję elementu, którego model treści nie jest EMPTY(na przykład pusty tytuł lub akapit), nie używaj zminimalizowanej formy (np. Użyj <p> </p>i nie <p />).

XHTML DTD określa elementy skryptu jako:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>

Aby dodać do tego, co powiedzieli Brad i squadette, samozamykająca się składnia XML jest w<script /> rzeczywistości poprawnym XML, ale aby działała w praktyce, Twój serwer internetowy musi również wysyłać dokumenty jako poprawnie sformatowany XML o typie XML podobnym do mate-riału HTTP Nagłówek Content-Type (a nie as ).application/xhtml+xmltext/html

Jednak wysłanie mimetype XML spowoduje, że strony nie będą analizowane przez IE7, co tylko polubi text/html.

Od w3 :

Podsumowując, „application / xhtml + xml” MUSI być używany w przypadku dokumentów rodziny XHTML, a użycie „text / html” MUSI być ograniczone do dokumentów zgodnych z HTML XHTML 1.0. Można również użyć „application / xml” i „text / xml”, ale w każdym przypadku POWINNY być używane „application / xhtml + xml” zamiast tych ogólnych typów nośników XML.

Zastanawiałem się nad tym kilka miesięcy temu, a jedynym wykonalnym (kompatybilnym z FF3 + i IE7) rozwiązaniem było użycie starej <script></script>składni z text/html(składnia HTML + typ mimetyczny HTML).

Jeśli Twój serwer wysyła ten text/htmltyp w swoich nagłówkach HTTP, nawet przy poprawnie sformatowanych dokumentach XHTML, FF3 + użyje trybu renderowania HTML, co oznacza, że <script />nie będzie działać (jest to zmiana, Firefox był wcześniej mniej rygorystyczny).

Stanie się tak bez względu na jakiekolwiek majstrowanie przy http-equivelementach meta, prologu XML lub doctype wewnątrz dokumentu - Firefox rozgałęzia się po otrzymaniu text/htmlnagłówka, który określa, czy parser HTML lub XML zagląda do dokumentu, a parser HTML nie rozumie <script />.

Jeśli ktoś jest ciekawy, ostatecznym powodem jest to, że HTML był pierwotnie dialektem SGML, który jest dziwnym starszym bratem XML. W SGML-land elementy mogą być określone w DTD jako samozamykające (np. BR, HR, INPUT), domyślnie zamykalne (np. P, LI, TD) lub jawnie zamykane (np. TABELA, DIV, SCRIPT). XML oczywiście nie ma na to pojęcia.

Parsery zupy tagów używane przez współczesne przeglądarki ewoluowały z tego dziedzictwa, chociaż ich model parsowania nie jest już czystym SGML. I oczywiście twój starannie spreparowany XHTML jest traktowany jako źle napisana zupa tagowa inspirowana SGML, chyba że wyślesz go z mimem XML. Dlatego też ...

<p><div>hello</div></p>

... zostaje zinterpretowany przez przeglądarkę jako:

<p></p><div>hello</div><p></p>

... który jest przepisem na piękny, niejasny błąd, który może wpaść w ciebie podczas próby kodowania DOM.

Inni odpowiedzieli „jak” i zacytowali specyfikację. Oto prawdziwa historia „dlaczego nie <script/>” po wielu godzinach zagłębiania się w raporty o błędach i listy mailingowe.

HTML 4

HTML 4 jest oparty na SGML .

SGML ma pewne shorttags , takie jak <BR//, <B>text</>, <B/text/, lub <OL<LI>item</LI</OL>. XML przyjmuje pierwszą formę, redefiniuje końcówkę jako „>” (SGML jest elastyczny), dzięki czemu staje się <BR/>.

Jednak HTML nie zmienił definicji, więc <SCRIPT/> powinno to znaczyć <SCRIPT>> .
(Tak, „>” powinno być częścią treści, a tag nadal nie jest zamknięty).

Oczywiście jest to niezgodne z XHTML i spowoduje uszkodzenie wielu witryn (do czasu, gdy przeglądarki będą wystarczająco dojrzałe, aby się tym przejmować ), więc nikt nie wdrożył shorttagów, a specyfikacja odradza .

W efekcie wszystkie „działające” samozakończone znaczniki są znacznikami z zabronionym znacznikiem końcowym w parserach niezgodnych pod względem technicznym i są w rzeczywistości nieprawidłowe. To W3C wymyślił ten hack, aby pomóc przejść do XHTML, dzięki czemu jest kompatybilny z HTML .

I <script>„s tag końcowy nie jest zakazane .

Tag „Self-ending” to hack w HTML 4 i jest bez znaczenia.

HTML 5

HTML5 ma pięć typów znaczników i tylko tagi „void” i „obcych” mogą być samozamykające .

Ponieważ <script>nie jest nieważny ( może mieć treść) i nie jest obcy (jak MathML lub SVG), <script>nie może być samozamykający się, niezależnie od tego, jak go używasz.

Ale dlaczego? Czy nie mogą uznać go za obcy, zrobić specjalny przypadek czy coś takiego?

HTML 5 ma być kompatybilny wstecz z implementacjami HTML 4 i XHTML 1. Nie jest oparty na SGML ani XML; jego składnia dotyczy głównie dokumentowania i łączenia implementacji. (Właśnie dlatego <br/> <hr/>itd. Są poprawne HTML 5, mimo że są nieprawidłowe HTML4.)

Samozamykanie <script>jest jednym ze znaczników, w których implementacje były różne. Jest wykorzystywany do pracy w Chrome, Safari , Opera i ; według mojej wiedzy nigdy nie działał w Internet Explorerze ani Firefoxie.

Zostało to omówione podczas opracowywania HTML 5 i zostało odrzucone, ponieważ narusza kompatybilność przeglądarki . Strony internetowe, które zamykają się automatycznie, mogą nie wyświetlać się poprawnie (jeśli w ogóle) w starych przeglądarkach. Były też inne propozycje , ale nie mogą też rozwiązać problemu ze zgodnością.

Po wydaniu wersji roboczej WebKit zaktualizował analizator składni, aby był zgodny.

Samozamykanie <script>nie występuje w HTML 5 z powodu wstecznej kompatybilności z HTML 4 i XHTML 1.

XHTML 1 / XHTML 5

Gdy naprawdę służy jako XHTML, <script/>jest naprawdę zamknięty, jak podają inne odpowiedzi .

Z wyjątkiem tego, że specyfikacja mówi, że powinna była działać, gdy jest serwowana jako HTML:

Dokumenty XHTML ... mogą być oznaczone etykietą Internet Media Type „text / html” [RFC2854], ponieważ są one kompatybilne z większością przeglądarek HTML.

Więc co się stało?

Ludzie prosili Mozillę, aby Firefox parsowała dokumenty zgodne ze standardem XHTML bez względu na określony nagłówek treści (znany jako wąchanie zawartości ). Pozwoliłoby to na samozamykające się skrypty, a wąchanie zawartości było i tak konieczne, ponieważ hosty internetowe nie były wystarczająco dojrzałe, aby wyświetlać poprawny nagłówek; IE był w tym dobry .

Jeśli pierwsza wojna przeglądarki nie zakończyła się na IE 6, XHTML mógł być również na liście. Ale to się skończyło. I IE 6 ma problem z XHTML. W rzeczywistości IE nie wspiera prawidłowy typ MIME w ogóle , zmuszając wszystkich do korzystania text/htmlz XHTML, ponieważ IE odbyła poważny udział w rynku na całe dziesięciolecia.

A także wąchanie treści może być naprawdę złe, a ludzie mówią, że należy go zatrzymać .

Wreszcie okazuje się, że W3C nie oznaczało, że XHTML może być wąchany : dokumentem jest zarówno HTML, jak i XHTML oraz Content-Typereguły. Można powiedzieć, że zdecydowanie „po prostu przestrzegaj naszej specyfikacji” i ignorując to, co było praktyczne . Pomyłka, że kontynuowane w późniejszych wersjach XHTML.

W każdym razie ta decyzja rozstrzygnęła sprawę dla Firefoksa. Minęło 7 lat, zanim narodził się Chrome ; nie było innej znaczącej przeglądarki. Tak postanowiono.

Samo określenie typu dokumentu nie powoduje analizowania XML ze względu na następujące specyfikacje.

Internet Explorer 8 i wcześniejsze nie obsługują parsowania XHTML. Nawet jeśli używasz deklaracji XML i / lub typu XHTML, stary IE nadal analizuje dokument jako zwykły HTML. I w zwykłym HTML, samozamykająca się składnia nie jest obsługiwana. Końcowy ukośnik jest po prostu ignorowany, musisz użyć jawnego znacznika zamykającego.

Nawet przeglądarki obsługujące parsowanie XHTML, takie jak IE 9 i nowsze wersje, nadal będą analizować dokument jako HTML, chyba że dokument zostanie udostępniony z typem treści XML. Ale w takim przypadku stary IE w ogóle nie wyświetli dokumentu!

Ludzie powyżej wyjaśnili już ten problem, ale jedną rzeczą, która może to wyjaśnić, jest to, że chociaż ludzie używają <br/>i tak przez cały czas w dokumentach HTML, każdy /w takiej pozycji jest w zasadzie ignorowany i używany tylko podczas próby coś zarówno analizowalnego jak XML i HTML. Spróbuj <p/>foo</p>na przykład, a otrzymasz zwykły akapit.

Samozamykający się tag skryptu nie będzie działał, ponieważ tag skryptu może zawierać kod wbudowany, a HTML nie jest wystarczająco inteligentny, aby włączyć lub wyłączyć tę funkcję na podstawie obecności atrybutu.

Z drugiej strony HTML ma doskonały znacznik do dołączania odwołań do zasobów zewnętrznych: <link>znacznik i może sam się zamykać. Jest już używany do dołączania arkuszy stylów, kanałów RSS i Atom, kanonicznych identyfikatorów URI i wszelkiego rodzaju innych gadżetów. Dlaczego nie JavaScript?

Jeśli chcesz, aby tag skryptu był samozamykający, nie możesz tego zrobić, jak powiedziałem, ale istnieje alternatywa, choć nie mądra. Możesz użyć tagu samozamykającego linku i linku do skryptu JavaScript, nadając mu typ text / javascript i rel jako skrypt, podobnie jak poniżej:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />

W przeciwieństwie do XML i XHTML, HTML nie ma wiedzy o składni samozamykającej. Przeglądarki, które interpretują XHTML jako HTML, nie wiedzą, że /znak wskazuje, że tag powinien się samozamykać; zamiast tego interpretują go jak pusty atrybut, a parser nadal uważa, że ​​tag jest „otwarty”.

Tak jak <script defer>jest traktowane jako <script defer="defer">, <script />jest traktowane jako <script /="/">.

Internet Explorer 8 i starszych nie obsługują odpowiedni typ MIME dla XHTML application/xhtml+xml. Jeśli podajesz XHTML as text/html, co musisz zrobić, aby te starsze wersje Internet Explorera zrobiły cokolwiek, będzie to interpretowane jako HTML 4.01. Krótkiej składni można używać tylko z dowolnym elementem, który pozwala na pominięcie znacznika zamykającego. Zobacz specyfikację HTML 4.01 .

„Skrócona forma” XML jest interpretowana jako atrybut o nazwie /, który (ponieważ nie ma znaku równości) jest interpretowany jako posiadający domyślną wartość „/”. Jest to całkowicie błędne w HTML 4.01 - niezadeklarowane atrybuty są niedozwolone - ale przeglądarki to zignorują.

IE9 i nowsze wersje obsługują XHTML 5 obsługiwany z application/xhtml+xml.

To dlatego, że TAG SKRIPU nie jest ELEMENTEM PUSTYM.

W dokumencie HTML - VOID ELEMENTS wcale nie potrzebują „tagu zamykającego”!

W xhtml wszystko jest ogólne, dlatego wszystkie wymagają zakończenia, np. „Tag zamykający”; W tym br, prosty podział linii, as <br></br>lub jego skrót <br /> .

Jednak element skryptu nigdy nie jest pustym ani parametrycznym elementem, ponieważ znacznik skryptu jest przede wszystkim instrukcją przeglądarki, a nie deklaracją opisu danych.

Zasadniczo semantyczna instrukcja kończąca, np. „Znacznik zamykający” jest potrzebna tylko do przetwarzania instrukcji, których semantyki nie można zakończyć przez kolejny znacznik. Na przykład:

<H1>semantyka nie może być zakończona przez następujące, <P>ponieważ nie ma wystarczającej ilości własnej semantyki, aby zastąpić, a zatem zakończyć poprzedni zestaw instrukcji H1. Chociaż będzie w stanie podzielić strumień na nową linię akapitu, nie jest on „wystarczająco silny”, aby zastąpić obecny rozmiar czcionki i wysokość linii stylu, zlewając strumień , tj. Wyciek z H1 (ponieważ P go nie ma ).

W ten sposób i dlaczego wynaleziono sygnalizację „/” (zakończenie).

Ogólny znacznik zakończenia bez opisu, taki jak < />, byłby wystarczający dla każdego pojedynczego upadku napotkanej kaskady, np .: <H1>Title< />ale nie zawsze tak jest, ponieważ chcemy również być w stanie „zagnieżdżać”, wielokrotne pośrednie tagowanie strumienia: split w torrenty przed owijaniem / spadaniem na inną kaskadę. W rezultacie ogólny terminator, taki jak < />, nie byłby w stanie określić celu właściwości do zakończenia. Na przykład: <b>pogrubienie <i>pogrubienie-kursywa < /> kursywa </> normalna. Bez wątpienia nie uda nam się zrealizować naszej intencji i najprawdopodobniej zinterpretuje ją jako odważną, odważną, metaliczną, odważną normalność.

Tak narodziło się pojęcie opakowania, tzn. Pojemnika. (Te pojęcia są tak podobne, że nie można ich rozróżnić, a czasami ten sam element może mieć oba. <H1>Jest jednocześnie opakowaniem i pojemnikiem w tym samym czasie. Natomiast <B>tylko opakowanie semantyczne). Będziemy potrzebować zwykłego kontenera bez semantyki. I oczywiście przyszedł wynalazek elementu DIV.

Element DIV jest tak naprawdę kontenerem 2BR. Oczywiście pojawienie się CSS sprawiło, że cała sytuacja była dziwniejsza niż w innym przypadku i spowodowała wielkie zamieszanie z wieloma wielkimi konsekwencjami - pośrednio!

Ponieważ w CSS można łatwo zastąpić natywne zachowanie przed i po BR nowo wynalezionego DIV, często nazywane jest to „kontenerem nic nie rób”. Co jest oczywiście błędne! DIV są elementami blokowymi i natywnie przerywają linię strumienia zarówno przed, jak i po sygnalizacji końcowej. Wkrótce sieć zaczęła cierpieć na stronę DIV-itis. Większość z nich jest nadal.

Pojawienie się CSS z możliwością pełnego zastąpienia i ponownego zdefiniowania natywnego zachowania dowolnego tagu HTML, w jakiś sposób zdezorientowało i zatarło całe znaczenie istnienia HTML ...

Nagle wszystkie tagi HTML wyglądały na przestarzałe, zostały zamazane, pozbawione pierwotnego znaczenia, tożsamości i celu. W jakiś sposób uzyskasz wrażenie, że nie są już potrzebne. Mówiąc: Pojedynczy znacznik opakowania byłby wystarczający dla wszystkich prezentacji danych. Po prostu dodaj wymagane atrybuty. Dlaczego zamiast tego nie mieć znaczących znaczników; Wymyślaj nazwy znaczników w trakcie pracy i pozwól CSS zawracać sobie głowę resztą.

Tak narodził się xhtml i oczywiście wielki tępak, który tak drogo opłacali nowi przybysze, i zniekształcona wizja tego, co jest i do czego to cholerny cel. W3C przeszło z World Wide Web na What Went Wrong, towarzysze? !!

Celem HTML jest przesyłanie znaczących danych do odbiorcy.

Aby dostarczyć informacje.

Część formalna ma na celu jedynie zwiększenie przejrzystości dostarczania informacji. xhtml nie uwzględnia w najmniejszym stopniu informacji. - Dla tego informacja jest absolutnie nieistotna.

Najważniejsze w tej sprawie jest to, aby wiedzieć i być w stanie zrozumieć, że xhtml to nie tylko wersja rozszerzonego HTML , xhtml to zupełnie inna bestia; podstawa; i dlatego mądrze jest trzymać je oddzielnie.

Różnica między „prawdziwym XHTML”, „fałszywym XHTML” i HTML, a także znaczenie typu MIME wysyłanego przez serwer zostały już tutaj dobrze opisane . Jeśli chcesz go teraz wypróbować, oto prosty edytowalny fragment kodu z podglądem na żywo, w tym samozamykający się tag skryptu dla odpowiednich przeglądarek:

div { display: flex; }
div + div {flex-direction: column; }

<div>Mime type: <label><input type="radio" onchange="t.onkeyup()" id="x" checked  name="mime"> application/xhtml+xml</label>
<label><input type="radio" onchange="t.onkeyup()" name="mime"> text/html</label></div>
<div><textarea id="t" rows="4" 
onkeyup="i.src='data:'+(x.checked?'application/xhtml+xml':'text/html')+','+encodeURIComponent(t.value)"
><?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[<!ENTITY x "true XHTML">]>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
  <p>
    <span id="greet" swapto="Hello">Hell, NO :(</span> &x;.
    <script src="data:text/javascript,(g=document.getElementById('greet')).innerText=g.getAttribute('swapto')" />
    Nice to meet you!
    <!-- 
      Previous text node and all further content falls into SCRIPT element content in text/html mode, so is not rendered. Because no end script tag is found, no script runs in text/html
    -->
  </p>
</body>
</html></textarea>

<iframe id="i" height="80"></iframe>

<script>t.onkeyup()</script>
</div>

Powinieneś zobaczyć Hello, true XHTML. Nice to meet you!poniżej textarea.

W przypadku niezdolnych przeglądarek możesz skopiować zawartość obszaru tekstowego i zapisać go jako plik z .xhtml(lub .xht) rozszerzeniem ( dzięki Alek za tę podpowiedź ).

Po prostu nowoczesna odpowiedź brzmi, ponieważ znacznik jest w ten sposób oznaczony jako obowiązkowy

Pominięcie znacznika Brak, zarówno początkowy, jak i końcowy znacznik są obowiązkowe.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script