Warum verwenden wir <script> für Skripte, aber nicht <style> für externes CSS?


76

Ein Verwandter von mir, der angefangen hat, Webentwicklung zu lernen, hat mir diese Frage gestellt.

Warum <script src="min.js"></script>und <link rel="stylesheet" href="min.css">? Warum nicht <style href="min.css"></style>. Warum verwenden wir linkTag, um externes CSS zur Seite hinzuzufügen, aber wenn wir CSS mit Seite verknüpfen, verwenden wir es, <style>...</style>wenn wir CSS in die Seite schreiben <head>?

Ich sagte ihm, dass es an der Spezifikation liegt. Gibt es weitere Informationen, die Sie ihm geben können?


6
Sie können dies auch tun : <style type="text/css">@import url("style.css");</style>.
Rocket Hazmat

1
@ Rocket, aber es ist nicht ratsam von Yslow Team Developer.yahoo.com/performance/rules.html#csslink
Jitendra Vyas

1
sie erwähnt Im IE @import das gleiche Ergebnis wie mit <link> am unteren Rand der Seite verhält, so ist es am besten nicht zu benutzen.
Jitendra Vyas

3
Ich dachte nur, ich würde einen anderen Weg aufzeigen, um die Dinge interessanter zu machen.
Rocket Hazmat

6
IE, es ist am besten, es nicht zu verwenden. FIFY
Rocket Hazmat

Antworten:


45

Es ist historisch ... Zufall? Sie können ihm empfehlen, einen Teil über Past of diveintohtml5.info zu lesen , in dem es einige interessante Geschichten zwischen Webentwicklern gibt, nämlich E-Mail-Korrespondenzen. Webentwickler bedeuten, dass sie tatsächlich das Web entwickelt haben, das wir heutzutage sehen;)

Dh <img>Tag, an den wir gewöhnt sind:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

könnte sein:

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

oder

<A HREF="..." INCLUDE>See photo</A>

oder

<INCLUDE HREF="...">

aber schließlich entschieden sich die Entwickler, bei dem zu bleiben <img>, was bereits implementiert wurde :

Wir sind derzeit nicht bereit, INCLUDE / EMBED zu unterstützen. … Also werden wir wahrscheinlich mitmachen (nicht ICON, da nicht alle Inline-Bilder sinnvoll als Symbole bezeichnet werden können). Inline-Bilder werden vorerst nicht explizit vom Inhaltstyp sein. In Zukunft planen wir, dies zu unterstützen (zusammen mit der allgemeinen Anpassung von MIME). Tatsächlich ermitteln die derzeit verwendeten Bildleseroutinen das Bildformat im laufenden Betrieb, sodass die Dateinamenerweiterung nicht einmal von Bedeutung ist.

Ich weiß keine direkte Antwort auf Ihre Frage, aber ich bin auch ziemlich neugierig auf <link>Tag. Das Finden einer Antwort würde wahrscheinlich das Ausgraben einiger Webarchive beinhalten.


1
Ich wollte gerade eine ähnliche Antwort schreiben - es ist wahrscheinlich nur eine Implementierungssache. Ein Browser implementierte es auf die eine Art und Weise, der andere tat etwas anderes und schließlich kam einer in die Spezifikation. Aber ich würde wirklich gerne von jemandem hören, der seinen Teil dazu gebracht hat, die Spezifikationen früher zu schreiben.
Easwee

1
Was auch immer in der Vergangenheit entschieden wurde, es ist in Ordnung, aber W3C kann sich in Zukunft beispielsweise in HTML 5 ändern text/cssund text/javascriptist nicht erforderlich.
Jitendra Vyas

Ich liebe diese Antwort, aber dies ist nicht die Antwort auf die eigentliche Frage im Kopf. Können wir vielleicht mehr Leute dazu bringen, dies zu kommentieren, damit wir die tatsächliche Antwort finden können?
Brainkim

27

Zumindest aus Sicht des W3C gibt es einen Unterschied.

Ein <style>Element führt einen Block von CSS-Regeln ein, die für das aktuelle Dokument gelten. Externe Stylesheets werden jedoch tatsächlich als ganze Dokumente betrachtet, die sich auf die aktuelle Seite beziehen , und Benutzeragenten können solche Dokumente je nach typeund mediaAttributen des Links ignorieren . Zum Beispiel:

<link rel="stylesheet" type="text/css" media="screen" href="screen.css" />
<link rel="stylesheet" type="text/css" media="print" href="print.css" />

In dieser Situation folgen Benutzeragenten normalerweise nur einem der Links, entweder dem screeneinen (für normales Rendern) oder dem printeinen (zum Drucken). Die Idee war, die Bandbreite zu erhalten, indem nur die entsprechende Ressource heruntergeladen wurde, anstatt alles abzurufen und später nach dem Medientyp zu filtern.

Dies wird in der Spezifikation erwähnt:

Wenn das LINKElement ein externes Stylesheet mit einem Dokument verknüpft, gibt das typeAttribut die Stylesheet-Sprache und das media Attribut das beabsichtigte Rendering-Medium oder Medium an. Benutzeragenten können Zeit sparen, indem sie nur die Stylesheets aus dem Netzwerk abrufen, die für das aktuelle Gerät gelten.


Wir können aber auch Medien in einer externen CSS-Datei definieren. Was heutzutage bevorzugt wird, um http-Anfragen zu speichern
Jitendra Vyas

1
@Jitendra, das können wir zwar, aber dann müssten wir die CSS-Datei herunterladen, um ihren Medientyp zu überprüfen. Durch das Einfügen dieser Informationen in das <link>Element kann der Benutzeragent die Ressource vollständig ignorieren, ohne sie zuerst laden zu müssen, bevor er sich dazu entschließen kann.
Frédéric Hamidi


2
Stilelemente unterstützen jedoch auch mediaAttribute wie: <style type="text/css" media="screen">Wir können zwei Stilelemente haben, eines für media="screen"und eines für media="print". Ich verstehe nicht, warum ein srcAttribut für ein Stilelement nicht zulässig ist.
user31782

2
@ user31782 Sie können beim W3C eine Petition einreichen, wenn Sie möchten, aber die Leute hier können nichts dagegen tun.
Pointy

4

Beide haben eine grundsätzlich identische Bedeutung, und Sie haben eine Art Inkonsistenz in HTML festgestellt. Der Grund dafür ist, dass die Standards auf der Implementierung verschiedener Browser basierten. Verschiedene Browser haben die Attribute in den verschiedenen Tags gefunden, und das W3C hat nur beschlossen, einige der Inkonsistenzen beizubehalten, um die Abwärtskompatibilität aufrechtzuerhalten.

Elemente, die verwenden src:script img iframe input video frame

Elemente, die verwenden href:a link base


7
Es gibt keine Inkonsistenz in HTML. srcwird für ersetzte Elemente verwendet. Diese Elemente sind Teil des HTML-Dokuments. While hrefwird zum Verknüpfen mit anderen Dokumenten verwendet. Hier geben wir eine 'Beziehung' des externen Dokuments zum aktuellen Dokument an.
Apnerve

2
@FelipeElia: Eigentlich würde ich argumentieren, dass die Verwendung <script>des srcAttributs 's kein Link, sondern ein Ersatz ist. Die Seite verhält sich identisch, unabhängig davon, ob Sie srcdas Skript inline verwenden oder einbinden (was als "Ersatz" angesehen wird).
Rinogo

1
@rinogo yep, du hast da einen guten Punkt! Wenn Sie jetzt darüber nachdenken, gilt dies auch für Bilder. Obwohl wir im Allgemeinen auf andere Dateien verweisen, können wir sie immer in base64 einbetten, was bei href-Elementen nicht der Fall ist. Um ein Inline-CSS zu verwenden, müssten wir <style> anstelle von <link> verwenden.
Felipe Elia


1

Das <link>Tag wird verwendet, um andere Dokumente mit dem aktuellen zu "verknüpfen" und seine Beziehung oder reldamit zu beschreiben.

Sie können auch <link>andere Dinge mit dem Dokument verknüpfen. Zum Beispiel Favicons:

<link rel="shortcut icon" href="favicon.ico" />

3
Zustimmen: Link kann verwendet werden, um auf viele Dinge zu verlinken (eine für jeden rel-Typ). Der wirklich überraschende Punkt an der Benutzeroberfläche ist also, warum nicht linkfür Skripte verwendet werden, wie hier gefragt .
Ciro Santilli 31 冠状 病 六四 事件 31

1

Möglicher Grund für link refvs style:

linkkann nur auf die gehen head, wo "Metadateninhalt" normalerweise erlaubt ist head,

stylekonnte nicht in die bodyvor HTML5 gehen (jetzt können Sie mit scoped, aber immer noch nicht zu externen Stilen). Daher ist die Wahl zwischen link refund style srcbeliebig.

scriptkonnte jedoch bereits ein externes Skript in das bodyvor HTML5 aufnehmen, so musste es sein script src. Aber da es existieren musste, warum nicht auch im head(wo scriptbereits erlaubt) zulassen und nicht zulassen link rel=script, um Doppelarbeit zu vermeiden?


Es ist eine schöne Antwort, aber <a> verwendet href und es war immer möglich, es im Körper zu haben ...
Felipe Elia
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.