Ist es eine schlechte Praxis, JavaScript in den HTML-Text einzubetten?

Question 1

Ein Team, an dem ich arbeite, hat es sich zur Gewohnheit gemacht, <script>Tags an zufälligen Stellen im Hauptteil unserer HTML-Seiten zu verwenden. Beispielsweise:

<html>
    <head></head>
    <body>
        <div id="some-div">
            <script type="text/javascript">//some javascript here</script>
        </div>
    </body>
</html>

Ich hatte das noch nie gesehen. Es scheint in den wenigen Browsern zu funktionieren, die ich getestet habe. Soweit ich weiß, ist es jedoch nicht gültig, Skript-Tags an solchen Stellen anzubringen.

Liege ich falsch? Wie schlimm ist es, dass wir Skript-Tags in solche div-Tags einfügen? Gibt es Probleme mit der Browserkompatibilität, die mir bekannt sein sollten?

Question 2

Es ist vollkommen gültig.

Sie möchten dort keine großen Codeblöcke in das Markup einfügen (besser externe Skripte verwenden), aber es kann nützlich sein, um:

Hinzufügen zusätzlicher Bindungsinformationen für die progressive Verbesserung (wenn es schwierig ist, diese Daten in einen Klassennamen oder einen anderen Ansatz zum Ausblenden erweiterter Informationen in Attributen zu integrieren); oder
wo es notwendig ist, eine Skript-Erweiterung so schnell wie möglich zu starten (anstatt auf das Laden von Fenstern / das Bereitstellen von Dokumenten zu warten). Ein Beispiel hierfür wäre der Autofokus, der bei zu spätem Feuern irritieren kann.

Möglicherweise denken Sie an <style>Elemente, die nicht zulässig sind <body>(obwohl die meisten Browser dies dennoch zulassen).

Question 3

Eigentlich ist es ziemlich häufig. Zum Beispiel Google Analytics-Tracking - Code Anwendungen gerade diese Syntax:

<script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

Wenn es für Google gut genug ist ...

Question 4

Es ist gültig und abhängig von Ihrem serverseitigen Framework und der Art des Codes manchmal sehr schwer zu vermeiden.

Question 5

Wie mehrere Leute erwähnt haben, ist es gültig, es funktioniert und es ist weit verbreitet.

Best Practices, soweit die Semantik dies empfiehlt (oder zumindest zur Empfehlung verwendet wird), bestehen darin, Skript-Tags in den Header einzufügen.

Modernere Best Practices, die die Leistung berücksichtigen, empfehlen, Skript-Tags (extern und inline) unten rechts vor dem Body-Tag zu platzieren, damit das Markup vollständig gerendert werden kann, bevor JavaScript-Code ausgeführt wird.

Zum leichteren Verständnis und zur Wartung des Codes wird "unauffälliges JavaScript" empfohlen, bei dem sich der Code in einer externen Datei befindet und Ereignisse an das DOM (Google unauffälliges JavaScript) bindet.

Ein Fall, in dem es nützlich ist, JavaScript inline zu haben, besteht darin, Variablen mit Werten zu initialisieren, die nur serverseitig vorhanden sind und die später vom externen JavaScript-Code verwendet werden.

Question 6

Ich ziehe es vor, Verweise auf externe Skripte in den Kopf zu setzen und Skripte, die Dinge starten und Widgets und so weiter in den Körper initialisieren.

Ein Problem, auf das man sehr leicht stoßen kann, ist, dass ein Skriptelement im Hauptteil nicht auf nachfolgende Elemente zugreifen kann. Ein ähnliches Problem mit der Browserkompatibilität ist die Tatsache, dass der IE es Skriptelementen nicht erlaubt, das Element zu ändern, in dem sie sich befinden. Wenn Sie also Folgendes haben:

<div id="foo">
  <script type="text/javascript">
    document.getElementById("foo")... // do something to it
  </script>
</div>

IE wird Ihre Seite nicht mögen. Alte Versionen des IE gaben sehr kryptische Fehlermeldungen für diese oder sogar die gesamte Seite aus, aber IE8 scheint eine beschreibende Fehlermeldung zu geben.

Solange Sie sicherstellen, dass Ihre Skripte nur auf DOM zugreifen, auf das sicher zugegriffen werden kann, halte ich es nicht für böse, Skriptelemente in den Body einzufügen. IMHO, das Einfügen von Skripten, die Widgets nach den zugehörigen Elementen initialisieren, kann besser lesbar sein, als alles an einem Ort abzulegen (und ich glaube, dies könnte auch dazu führen, dass sie früher ausgeführt werden, wodurch die Dinge beim Laden der Seite weniger herumspringen).

Question 7

Es ist gültig!

Sie können verwenden:

<script type="text/javascript">
    //<![CDATA[

    // Some JavaScript code that perfectly validates in the W3C validator

    //]]>
</script>

Ich glaube nicht, dass man sagen kann, ob es im Allgemeinen eine schlechte Praxis ist. Sie müssen in dem Fall sagen. Aber sicher ist es gut, dass Sie Ihren gesamten JavaScript-Code am selben Ort haben. Es ist ein wenig chaotisch, wenn Sie überall in Ihrer HTML-Datei kleine Teile von JavaScript-Code haben.

Question 8

Ich hatte das noch nie gesehen. Es scheint in den wenigen Browsern zu funktionieren, die ich getestet habe. Soweit ich weiß, ist es jedoch nicht gültig, Skript-Tags an solchen Stellen anzubringen.

Es ist gültig, aber keine gute (oder empfohlene) Praxis.

Liege ich falsch? Wie schlimm ist es, dass wir Skript-Tags in solche div-Tags einfügen? Gibt es Probleme mit der Browserkompatibilität, die mir bekannt sein sollten?

Es ist kein Problem, ein <script>unter anderen Elementen zu platzieren (aber es sollte sich in <head>oder befinden <body>). Es gibt auch keine Probleme hinsichtlich der Browserkompatibilität. Das Einbetten von JS-Skripten in Webseiten weist jedoch schwerwiegende Nachteile auf (wie / warum sie als schlecht angesehen werden) :

Fügt Seitengewicht hinzu
Schwierigkeiten (oder wahrscheinlich unmöglich) bei der Minimierung
Kann nicht migriert oder für andere Seiten verwendet werden
Kann nicht zwischengespeichert werden (muss bei jedem Laden der Seite heruntergeladen werden)
Keine Trennung von Bedenken (schwerer zu pflegen)

Question 9

Es ist jedoch auch gut, dass Sie wissen, dass der für einen HTML-Abschnitt erforderliche JavaScript-Code dafür verfügbar sein wird. Anstatt eine Aufnahme oben in der Datei behaupten und aufbauen zu müssen.

Anstatt "Wenn Sie diesen HTML-Code verwenden möchten, stellen Sie sicher, dass Sie xyz.js importieren", können Sie einfach den HTML-Code einbinden und damit fertig sein.

Es ist also nicht unbedingt schrecklich böse. Vielleicht nicht spektakulär großartig, aber auch nicht absolut schrecklich. Es hängt irgendwie von der Absicht ab.

Question 10

Best Practice finden Sie in der Yahoo-Benutzeroberfläche: http://developer.yahoo.com/performance/rules.html (JavaScript am Ende der Seite)

Question 11

Es ist sicherlich legal; Ich habe es auf einigen Seiten hier bei Exforsys gesehen zum Beispiel .

Dies ist eine Tutorial-Site, die die Grundlagen von HTML und JavaScript zeigt, sodass sie in diesem Zusammenhang vollkommen verständlich ist. Ich würde es jedoch nicht gerne im Produktionscode für mehr als ein oder zwei einfache Anweisungen sehen. Ohne zu sehen, durch was Sie ersetzt haben, // Some JavaScript code heremöchte ich keinen Kommentar abgeben.

Es sollte jedoch keine Browserprobleme geben.

Question 12

Es ist gültig, <script> hinzuzufügen body , aber Internet Explorer mag es wirklich nicht. Um auf der sicheren Seite zu sein, stellen Sie sicher, dass sich Ihre Skripte im <head> -Tag befinden.

Das hat in dem Projekt, an dem wir arbeiten, wirklich Chaos verursacht (insbesondere für Internet Explorer).

Question 13

Ich gehe davon aus, dass Ihr Team dies entweder tut, weil es ein Skript dynamisch einfügen möchte, oder weil es ein Skript schreibt, das beim Laden der Seite ausgelöst wird.

Ich würde nicht sagen, dass daran etwas falsch ist, wenn dies ABSOLUT NOTWENDIG ist (solange es sich in einem CDATA-Block befindet), aber darüber hinaus würde ich Ihrem Team empfehlen, eine Skriptbibliothek wie Prototype oder jQuery zu verwenden und zu behalten die Skripte außerhalb der Seite. Dies ist normalerweise sauberer und Bibliotheken erzwingen manchmal ein wenig Sauberkeit im Code, was meiner Meinung nach derzeit nicht geschieht.

Ich würde auch keine zeitaufwändigen Funktionen in Inline-Skript-Tags ausführen, da diese beim Laden der Seite auftreten und, wie Jason oben angegeben hat, das Laden der Seite verlangsamen könnten. Alle Skriptbibliotheken verfügen über übersichtliche Funktionen, mit denen Sie beim Laden der Seite Aufgaben ausführen können. Sie haben die Möglichkeit, sie beim Laden der Seite auszulösen, z. B. nachdem das DOM geladen wurde.

Question 14

Es ist eine von vielen, vielen Best Practices, bei denen es sowohl um die Verbesserung der Leistung als auch um die Verbesserung Ihres Programmieransatzes geht.

Letztendlich ist es in der Webentwicklung am wichtigsten, das Produkt herauszubringen!

Question 15

Es ist absolut gültig, kann jedoch die Wartbarkeit beeinträchtigen. Siehe auch Wo soll ich <script> -Tags in HTML-Markups einfügen? und warum schlägt der Aufruf dieser jQuery-Funktion in Firefox fehl? .

Question 16

Die oft genannte Empfehlung, Skripte im Header zu behalten, besteht darin, sicherzustellen, dass das Skript geladen wird, bevor es aufgerufen wird. Dies ist nur für bestimmte Ereignishandler ein Problem. Bei anderen Skripttypen spielt dies keine Rolle, und bei einigen Typen (z. B. document.write) ergibt dies keinen Sinn.

Question 17

Wenn Sie einen Editor haben, der gleichzeitig HTML- und JavaScript-Syntax verarbeiten kann. Und wenn Sie zuerst ein paar Zeilen HTML und dann JavaScript cpde lesen möchten ... sicher. Tue es.

Question 18

Ein paar Dinge:

Es ist in Bezug auf den Code vollständig gültig.
Es ist völlig unempfehlenswert.

Dadurch wird die Seitenlast erheblich verlangsamt, da der JavaScript-Code ausgeführt werden muss, bevor der Rest der Seite gerendert werden kann. Wenn Sie viel mit diesem JavaScript-Code arbeiten, kann Ihr Browser hängen bleiben. Sie sollten versuchen, (wann immer möglich) Ihren JavaScript-Code dynamisch und am Ende Ihrer Seite (vorzugsweise vor dem </body>Tag) zu laden .

Kaufen und lesen Sie Hochleistungs-JavaScript . Dies ändert die Art und Weise, wie Sie JavaScript-Code schreiben.