Ich habe eine tolle Frage vom Leser Josh Kreis erhalten
Mir ist aufgefallen, dass es bei einem
<script>-Tag alle möglichen Variationen gibt, die alle browserübergreifend zu funktionieren scheinen. Was ist notwendig und was nicht?
<script>
//some javascript here
</script>
<script type="text/javascript">
//some javascript here
</script>
<script type="text/javascript" language="javascript">
//some javascript here
</script>
<script language="javascript">
//some javascript here
</script>
<script type="text/javascript">
//<![CDATA[
// some javascript here
//]]>
</script>
Das ist der Stand der Dinge, soweit ich das verstehe. Wenn jemand etwas hinzufügen oder mich korrigieren möchte, wenn ich falsch liege, bitte tun Sie das in den Kommentaren.
/* WAY OLD - DO NOT USE */
<script language="javascript">
//some javascript here
</script>
Es gab nie wirklich ein language-Attribut (oder wenn, dann ist es längst veraltet). Es gibt ein lang-Attribut, aber das dient einem völlig anderen Zweck: die menschliche Sprache zu identifizieren, nicht die Computersprache. Diese Syntax mit dem language-Attribut diente dazu, (älteren) Browsern mitzuteilen, dass sie das Skript als JavaScript identifizieren und ausführen sollen. Es funktionierte früher, war aber nie Standard.
Jetzt haben wir eine standardisierte Methode dafür
<script type="text/javascript">
//some javascript here
</script>
Das type-Attribut ist der Standard und der korrekte Weg, um dem Browser mitzuteilen, welche Art von Skript das Tag enthält. Manchmal sehen Sie Code, der sowohl das language- als auch das type-Attribut verwendet. Soweit ich weiß, ist das nie notwendig.
Wirklich spezifische Erklärung aus der Spezifikation, language ist ein "veraltetes, aber konformes" Feature
Autoren sollten kein language-Attribut auf einem Skriptelement angeben. Wenn das Attribut vorhanden ist, muss sein Wert eine ASCII-Groß-/Kleinschreibung-unabhängige Übereinstimmung mit der Zeichenkette "JavaScript" sein und entweder das type-Attribut muss weggelassen werden oder sein Wert muss eine ASCII-Groß-/Kleinschreibung-unabhängige Übereinstimmung mit der Zeichenkette "text/javascript" sein. Das Attribut sollte stattdessen vollständig weggelassen werden (mit dem Wert "JavaScript" hat es keine Auswirkung) oder durch die Verwendung des type-Attributs ersetzt werden.
In jüngerer Zeit haben Sie wahrscheinlich viel von diesem hier gesehen
<script>
//some javascript here
</script>
Keine Attribute. Das ist der HTML5-Weg, Skript-Tags mit JavaScript zu handhaben. Es wird einfach davon ausgegangen, dass der Typ text/javascript ist. Wenn das nicht der Fall ist (ich habe noch nie einen anderen Skripttyp gesehen), müssen Sie ihn mit dem type-Attribut ändern. Das empfehle ich, wenn Sie HTML5 verwenden.
Noch eine seltsame Sache
<script type="text/javascript">
//<![CDATA[
$("<div />").appendTo("body"); // Some JS with HTML in it.
//]]>
</script>
FALLS Sie immer noch XHTML verwenden und FALLS Ihr JavaScript HTML enthält (oder sogar nur das <-Zeichen, wie es bei Greater-than-Logik erforderlich sein könnte), benötigen Sie diese CDATA-Kommentare um das Skript herum, FALLS Sie möchten, dass das Skript die Validierung besteht (Sie erhalten eine Fehlermeldung wie: Dokumenttyp lässt Element "div" hier nicht zu). UND FALLS Sie Skript buchstäblich zwischen den öffnenden und schließenden Skript-Tags einfügen, anstatt eine Skriptquelle (src) zu verlinken.
Das sind viele WENN-Fälle.
Fazit
- Wenn Sie HTML5 verwenden, verwenden Sie einfach
<script>. - Wenn Sie etwas Älteres verwenden, verwenden Sie
<script type="text/javascript">. - Wenn Sie Skripte für die Verwendung auf fremden Websites schreiben (z. B. Copy-Paste-Code, WordPress-Plugins usw.), verwenden Sie
<script type="text/javascript">und CDATA.
Danke für die Klarstellung! Ich habe mich immer gefragt, warum. Ich bin froh, dass HTML5 jetzt viel einfacher ist.
Weiß jemand von anderen Typen, die im Skript-Tag verwendet werden? Ich habe auch noch nie etwas anderes als JavaScript darin gesehen.
Viele clientseitige Template-Engines (z. B. jQuery-Templates) verwenden das Skript-Tag zur Definition von Templates. Sehen Sie dieses Beispiel.
„Ich habe noch nie einen anderen Skripttyp gesehen“
Wenn es etwas wert ist, können Sie
type="text/coffeescriptmit dem CoffeeScript-Interpreter im Browser verwenden. Beispiel hier: http://joshuacc.github.com/LifeForce/Toller Beitrag, ich werde die Leute hierher schicken, wenn sie mir sagen, dass ich das type-Attribut verwenden MUSS (obwohl ich HTML5 schreibe).
Für verlinkte Dateien… ist es nicht genau dasselbe?
@Rob, ja, ich habe VBScript schon auf einigen alten Websites gesehen.
type=”text/vbscript”
Und ich habe vor ein paar Jahren ein einfaches VBScript geschrieben.
Man kann auch eine JavaScript-Version so ansteuern
type=”text/javascript1.3″
Aber das habe ich noch nicht gesehen.
Googles Page Speed-Erweiterung für den Chrome Web Inspector zieht Punkte ab, wenn das type-Attribut für Skript- und verlinkte CSS-Elemente nicht angegeben wird. Die Angabe des MIME-Typs in einer .htaccess-Datei reicht dafür nicht aus.
Ich bin mir nicht sicher, ob es tatsächlich Auswirkungen auf die Ladezeiten von Seiten hat, aber da Google die Seitenladezeiten in den Suchrankings berücksichtigt, kann es nicht schaden, die type-Attribute weiterhin hinzuzufügen, wenn es Google glücklich macht!
Dennoch bin ich mir nicht sicher, ob Googlebot dieselben Kriterien für die Seitenoptimierung verwendet wie die Web Inspector-Erweiterung, aber ich werde sie trotzdem weiterhin verwenden.
Danke für den Tipp, Jonic. Das ist ein ausgezeichneter Punkt!
Hast du es auf einer HTML5-Website überprüft oder war es von einem anderen Standard?
Ich erinnere mich, dass man mit dem Skript-Tag zu PHP wechseln kann?
Vielleicht denkst du an das Abrufen eines JS-Skripts, das von einer PHP-Datei generiert wird?
Sie können natürlich die <% … %>- und <%php … php%>-Tags verwenden, um innerhalb einer Datei zu PHP zu wechseln.
Ja, darüber habe ich hier geschrieben
http://www.impressivewebs.com/php-file-html-script-tag/
Man kann im Grunde jede Art von Datei über das Skript-Tag aufrufen, aber das Ergebnis muss tatsächlich JavaScript zurückgeben, damit es auf der Seite etwas tun kann.
Die spezielle Interpretation von Zeichen in CDATA-Abschnitten hat nichts mit der Validierung zu tun. Sie erhalten einen XML-Parsing-Fehler beim Laden der Seite oder bevor die Validierung stattfindet. Es ist einfach eine Abkürzung, damit Sie nicht Entitäten wie < in Ihren Skripten verwenden müssen. Wenn Sie die XML-Syntax verwenden, sind diese JavaScript-Kommentare vor dem CDATA unnötig – das ist wirklich der einzige Grund, warum Sie CDATA überhaupt verwenden würden, es sei denn, Sie versuchen, polyglotte Codes zu schreiben, was in letzter Zeit etwas weniger in Mode gekommen ist.
Ebenfalls ausgelassen ist wahrscheinlich das häufigste Missverständnis bezüglich "application/javascript" gegenüber "text/javascript". Ich sehe das language-Attribut heutzutage selten.
Für reines JavaScript benötigen Sie nur ein Skriptelement ohne Attribute. Der MIME-Typ ist nicht erforderlich, da JS der Standard ist. Wenn Sie eine eigene Sprache angeben möchten, wird der MIME-Typ interessant. Die Kommentare innerhalb der Skriptknoten sind rein historisch, kein derzeit verwendeter Client kümmert sich um den Inhalt eines Skriptknotens zur Anzeige.
Ich habe festgestellt, dass ich immer noch gerne verwende
script type=”text/javascript”
AUCH BEI VERWENDUNG VON HTML5 – so weiß mein Code-Editor immer noch, wie er die Syntax hervorheben soll. Ich benutze Coda, gibt es eine Möglichkeit, es JS ohne type=”text/javascript” erkennen zu lassen?
Ja, pack das JavaScript in eine separate Datei
Der wichtigste Teil der Information fehlt… nämlich dass es am besten ist, JavaScript in seine eigene externe .js-Datei zu packen, anstatt in das (X)HTML-Dokument. IDEALERWEISE würden Sie also nur das hier tun
HTML5
<script src=”yourscript.js”></script>
Alles Ältere
<script src=”yourscript.js” type=”text/javascript”></script>
Keine Notwendigkeit, sich überhaupt um diesen hässlichen CDATA-Kram zu kümmern.
Der Grund, warum HTML5 das Erfordernis des type-Attributs abschafft*, ist, dass kein Browser** sich überhaupt darum kümmert. Der Doctype/die angegebene HTML-Version hat darauf keinen Einfluss.
* für JavaScript
** Kein _häufig verwendeter_ Browser
(und die meisten ungewöhnlichen Browser auch)
Richtig, aber ich würde das type-Attribut für alles Nicht-HTML5 immer noch aus Validierungsgründen angeben. Sie haben Recht, kein Browser kümmert sich überhaupt darum, ob der Typ vorhanden ist oder nicht. Aber er war in früheren Versionen erforderlich, um "gültig" zu sein, also wenn Sie irgendeine Art von Validierung durchführen, verhindert die Angabe des Typs Validierungsfehler.
Stimmt.
(Ich kümmere mich wohl weniger um Validierung als um Praktikabilität.)
„es ist am besten, JavaScript in seine eigene externe .js-Datei zu packen“
Vielleicht semantisch der beste Weg, aber es ist auch eine zusätzliche HTTP-Anfrage, also… nicht immer die beste Idee meiner Meinung nach.
Nur zur Info – minimaler Test mit Auslassung des type-Attributs bei <style> und <script>. Gültig gemäß http://syntax.whattf.org/relaxng/xhtml5.rnc und nicht gemäß http://www.w3.org/MarkUp/RELAXNG/xhtml-rdfa-1.rng
Also, altes XHTML braucht type zur Validierung, ansonsten ist jedes HTML5 in Ordnung, und kein Browser sollte damit Probleme haben.
Die xhtml5 RNG stürzt bei den HTTP-Metadaten ab, aber ich glaube, das ist ein Bug.
Nicht vergessen
Natürlich kann dies mit allen oben genannten Optionen kombiniert werden, um ein noch mehr enterprisey Feeling zu erzielen.
Ich habe gerade neulich über dieses Thema nachgedacht… schönes Timing. Danke für die Klärung!
Ein weiterer Fall für CDATA, auf den ich regelmäßig gestoßen bin, ist die Verwendung einer Template-Engine wie Genshi für Python zur Generierung von HTML. Es versucht oft, zu schlau zu sein und <>s im JavaScript in &-Entitäten umzuwandeln.
Das Gleiche gilt, wenn Sie sie auch in CSS verwenden. Das führt zur komischen Syntax von
<style type="text/css"> /* <![CDATA[ */ .someelement:after { content: ">"; } /* ]]> */ </style>Übrigens: Kann das type=”” auch für Style in HTML5 weggelassen werden?
Ja, das
type-Attribut kann für<style>-Elemente und auch für<link rel=stylesheet>weggelassen werden. Siehe HTML5 Level 1 für weitere neue HTML5-Sachen, die überall funktionieren™.Anstatt nur "In HTML5" zu sagen…
Es könnte sich lohnen zu erwähnen
<!doctype html>
sollte der Doctype sein, wenn Sie
<script>
//einige JavaScript hier
</script>
Ich möchte noch einmal auf den Fall von Handlebars-Templates hinweisen, die in Skript-Tags enthalten sind
Handlebars wird in YUI3 integriert, ein weiterer Grund, darauf hinzuweisen.
Nochmals vielen Dank für den Beitrag!
Ich würde sagen, verwenden Sie immer
<script>, egal ob HTML 4 oder 5. Alle Browser standardisieren auf JavaScript, und das schon so gut wie ewig.Übrigens: Es könnte in Zukunft
type="application/dart"geben (zumindest in Chrome).Ich möchte nur noch hinzufügen (obwohl nicht unbedingt erforderlich): Ich bin Blogger-Nutzer und stelle fest, dass die Verwendung von
//<![CDATA[wichtig ist. Denn wenn nicht, werden einfache Anführungszeichen als'und Anführungszeichen als"interpretiert. Außerdem lehnt Blogger ohne//<![CDATA[die JQuery-Anweisung$ ('.something').append('<div></ div>');ab.Er erwartete, dass es sich um ein HTML-Element handelt, das im
<head>platziert wirdKönntest du deinen nächsten Artikel über das
<style>-Tag machen? Dieser hier ist großartig, Chris!سلام.خسته نباشید.من از ایران شهر ممقان هستم.
از زحمات شما تشکر میکنم.
————————–
Hallo, ich bin Alireza aus Iran. Bundesland Mamaghan.
Danke für alles.
Ich glaube, ich habe eine andere Variante gesehen
hmm, ich habe die pre- und code-Tags hinzugefügt, aber es hat nicht funktioniert.
Jedenfalls meinte ich, manchmal gibt es ein charset-Attribut: charset=”utf-8″
Hier ist ein weiterer guter Artikel zu diesem Thema
http://www.hixie.ch/advocacy/xhtml
Toller Artikel! kleiner Tippfehler im HTML5-Teil, letzter Satz
„Ich empfehle dies ist, wenn Sie HTML5 verwenden.“
Sollte heißen "Ich empfehle dies, wenn Sie HTML5 verwenden." (ist / if), nehme ich an.
Und vielleicht sogar ein Komma?
Machen Sie weiter so, das ist eine der wenigen Seiten, die ich regelmäßig, wenn nicht sogar täglich besuche.
Nur zur Info: Ich erinnere mich, dass Crockford die Entfernung des type-Attributs befürwortete, weil er es nicht als etwas anderes als text/javascript in der Zukunft sah – und es keinen Nachteil hatte, dies in modernen Browsern zu tun.
Der alte <!– –>-Stil innerhalb von <script> war für Browser gedacht, die <script> nicht verstanden, und verhinderte, dass sie den Inhalt des Blocks als Text renderten. (Netscape 4 mit deaktiviertem JS, vielleicht, oder ältere/frühere Versionen von Browsern wie Mosaic? Ich weiß es nicht mehr.)
Zu anderen Sprachen: mit Silverlight werden auch IronRuby & IronPython unterstützt.
Das ist ein schönes und gutes Futter für den Kopf, eine weitere gute Lektion, danke Chris!
Jetzt benutze ich immer so
Es gibt keinen Bedarf für type oder etwas anderes. Und übrigens kann der Server so eingerichtet werden
wenn Verzeichnis css ist, dann default_type text/css; wenn js dann default_type text/js; etc..
Ebenso ist es nicht nötig, Meta-Tags für Charset und andere hinzuzufügen
add_header X-UA-Compatible IE=Edge,chrome=1;
add_header charset utf-8;
Diese Codes sind im HTML nicht nötig, da der Server sie erledigen kann.
Ja, ohne Anführungszeichen
Ich bin mir ziemlich sicher, dass das „language“-Attribut von Microsoft mit Internet Explorer eingeführt wurde[1], damit Sie neben dem üblichen Standard JavaScript auch VBScript oder JScript handhaben konnten (JScript hatte einige geringfügige Verbesserungen gegenüber JavaScript, war aber im Wesentlichen JavaScript[2]). IE konnte auch PerlScript, eine auf Perl basierende Sprache, durch die Verwendung von Erweiterungen verarbeiten[3]. Diese Funktionalität wird über das Windows Scripting Host[4] bereitgestellt, das auch auf die Verwendung eines language-Tags zur Unterscheidung zwischen verschiedenen Sprachen hinzuweisen scheint.
[1] http://msdn.microsoft.com/en-us/library/aa242461(v=vs.60).aspx
[2] http://en.wikipedia.org/wiki/JScript
[3] http://www.xav.com/perl/Components/Windows/PerlScript.html
[4] http://en.wikipedia.org/wiki/Windows_Script_Host
Guter Artikel
HTML5 war nur so einfach. Jetzt weiß ich XD
Toller Artikel… danke Chris!
Toller Artikel… danke Chris! Mach weiter so mit so wertvollen Artikeln… Danke nochmal
Wir verwenden ein Skript-Tag im Frontend des CMS, das wir Umbraco nennen. Es basiert auf ASP.Net, aber wir verwenden das Tag und fügen ein runat=”server” hinzu und können dann C#-Code direkt zwischen den Blöcken im Umbraco-Template hinzufügen.
Das ist eine weitere Möglichkeit, das Tag zu verwenden. Ich denke, es ist am besten, den Typ zum Tag hinzuzufügen, nur um sicher zu gehen, egal ob in HTML5 oder nicht. Dann haben Sie immer einen Fallback, wenn ältere Browser die HTML5-Elemente nicht lesen können, aber trotzdem JavaScript auf der Seite ausführen können. Besonders wenn Ihre Dropdown-Menüs von JavaScript gesteuert werden. Dann kann ein Benutzer zumindest auf der Website navigieren, wenn er die HTML5-Elemente nicht anzeigen kann.
runat=”server” ist eine ASP.NET-Sache. Dies ist kein Teil einer HTML-Spezifikation und Benutzer werden dies nie sehen (da es auf dem Server ausgeführt wird). Es wird jedoch generell als schlechte Praxis angesehen – der richtige Weg ist die Verwendung von Code-Behind-Dateien (.aspx.cs). Ich bin mir nicht sicher, ob Umbraco dies zulässt.
Daniel,
Wir kennen die Code-Behind-Sachen. Das Skript-Tag runat=”server” führt tatsächlich eine extrem einfache UA-Erkennung durch und fügt „/mobile“ zur URL hinzu. Umbraco erlaubt die Verwendung alternativer Templates für Ihre Website, ohne eine komplett neue Website erstellen oder zu einer m.mydomain.com-ähnlichen Seite weiterleiten zu müssen. Wir nutzen die alternativen Templates, indem wir das Skript runat=”server” nur dafür verwenden.
Der Rest der Website basiert auf der Plattform von Umbraco. Wir haben natürlich einige benutzerdefinierte Steuerelemente, die mit Code-Behind-Dateien erstellt wurden.
Wenn Sie C# oder ASP.Net kennen, empfehle ich, es zumindest auszuprobieren. Es ist ein ziemlich cooles CMS. Sehr erweiterbar. Auch wenn Sie C# oder ASP.Net nicht kennen, schauen Sie es sich trotzdem an. Sie müssen keine der beiden Sprachen kennen, um eine Website in Umbraco zu erstellen. Grundlegendes HTML und CSS sind hauptsächlich das, was Sie brauchen.
Aber ja.
Ich habe nur gesagt, dass Skript-Tags in ASP.Net für diejenigen, die es nicht wissen, verwendet werden können, um Serverseiten-Stuff von der Clientseite mit runat=”server” zu erledigen.
Das language-Attribut ist definitiv veraltet und sollte für die aktuelle Webentwicklung niemals verwendet werden. Früher wurde das Attribut von Browsern verwendet, um den Sprach-Typ und die minimale erforderliche Parser-Version anzugeben. Beispiel:
<script language="JavaScript1.5">bedeutete, dass die Parsing-Engine Version 1.5 der JavaScript-Sprache unterstützen sollte, um das Skript auszuführen. Wenn der Browser die Version nicht unterstützte, führte er das Skript nicht aus. Heutige Browser verwenden diese Art von Bezeichnung nicht mehr. Die Verwendung vontry {} catch {}in JavaScript war ein Paradebeispiel für die Notwendigkeit, die Skriptunterstützung zu kennen. Die Sprache und die Implementierung waren früher begrenzt und entwickelten sich noch, und der Code konnte Fehler verursachen, anstatt sie abzufangen, wenn er nicht unterstützt wurde.