Vergleich des Ladens von CSS inline, eingebettet und von externen Dateien

7

Wir können CSS wie folgt schreiben:

  1. Inline-CSS
  2. Eingebettetes CSS
  3. Externes CSS

Ich würde gerne die Vor- und Nachteile von jedem wissen.

    
RedsDevils 16.03.2010, 15:07
quelle

10 Antworten

10

Es kommt darauf an, wo in der Pipeline das CSS ist, wie ich es sehe.

1. Inline CSS

Vorteile: Ideal für schnelle Fixes / Prototyping und einfache Tests, ohne zwischen dem .css-Dokument und der eigentlichen HTML-Datei hin- und herwechseln zu müssen.

Vorteile: Viele E-Mail-Clients erlauben die Verwendung externer CSS-Referenzierung aufgrund von möglichem Spam / Missbrauch nicht. Einbetten könnte helfen.

Nachteile: Füllt HTML-Speicherplatz auf / benötigt Bandbreite, nicht über mehrere Seiten hinweg - nicht einmal IFRAMES.

2. eingebettetes CSS

Vorteile: Wie oben für den Prototyp, aber einfacher aus dem endgültigen Prototyp herauszuschneiden und in eine externe Datei einzufügen, wenn die Vorlagen fertig sind.

Nachteile: Einige E-Mail-Clients erlauben keine Stile in [head], da die head-Tags von den meisten Webmail-Clients entfernt werden.

3. externe CSS

Vorteile: Einfache Pflege und Wiederverwendung über Websites mit mehr als einer Seite.

Vorteile: Cacheable = weniger Bandbreite = schnelleres Rendern der Seite nach dem Laden der zweiten Seite

Vorteile: Externe Dateien, einschließlich .css, können auf CDN gehostet werden und machen dadurch weniger Anfragen an die Firewall / den Webserver, der die HTML-Seiten hostet (falls auf verschiedenen Hosts).

Vorteile: Kompilierbar, Sie könnten automatisch den gesamten ungenutzten Speicherplatz aus dem endgültigen Build entfernen, genau wie jQuery eine Entwicklerversion und eine komprimierte Version = schnellerer Download = schnellere Benutzererfahrung + weniger Bandbreite = schnelleres Internet! (Wir mögen !!!)

Nachteile: Normalerweise aus HTML-Mails entfernt = chaotisches HTML-Layout.

Nachteile: Macht eine zusätzliche HTTP-Anfrage pro Datei = mehr Ressourcen in den Firewalls / Routern.

Ich hoffe, du könntest etwas davon benutzen?

    
BerggreenDK 16.03.2010, 15:27
quelle
6

Ich werde die Meinung einreichen, dass externe Stylesheets der einzige Weg sind.

  • Inline-CSS mischt Inhalte mit Präsentationen und führt zu einem schrecklichen Durcheinander.

  • eingebettete CSS wird mit jeder Seitenanforderung geladen, Änderungen können nicht über mehrere Seiten hinweg geteilt werden, und der Inhalt kann nicht zwischengespeichert werden.

Ich habe nichts gegen beide Methoden an sich, aber wenn Sie eine neue Site oder Anwendung planen, sollten Sie externe Stylesheets einplanen.

    
Pekka 웃 16.03.2010 15:09
quelle
5

Inline

Schnell, aber sehr schmutzig

Dies ist (leider) auch die einzige wirklich vernünftige Option für HTML-formatierte E-Mails, da andere Formulare oft von verschiedenen E-Mail-Clients verworfen werden.

Eingebettet

Erfordert keine zusätzliche HTTP-Anforderung, hat jedoch nicht die folgenden Vorteile:

Verknüpft

Kann zwischengespeichert, zwischen den Seiten wiederverwendet werden, einfacher mit Validatoren getestet werden.

    
Quentin 16.03.2010 15:09
quelle
1

Sie wollen externe CSS. Es ist am einfachsten zu pflegen, externe CSS vereinfacht auch das Caching. Eingebettet bedeutet, dass jede separate HTML-Datei ihre eigene CSS-Datei haben muss, was eine größere Dateigröße und viele Kopfschmerzen beim Ändern der CSS-Datei bedeutet. Inline CSS ist noch schwieriger zu pflegen.

Externe CSS ist der Weg zu gehen.

    
adamse 16.03.2010 15:10
quelle
1

Wo soll ich anfangen? ??

Angenommen, Sie hatten eine Seite mit 3 Seiten ... Sie könnten mit Inline-CSS (d. H. CSS auf der Seite selbst, innerhalb von Tags) durchkommen.

Wenn Sie eine 100-seitige Website hätten ... Sie möchten das CSS nicht auf jeder Seite einzeln ändern (oder würden Sie?!) ... Ein externer CSS-Sheet wäre also der bessere Weg.

    
Barrie Reader 16.03.2010 15:10
quelle
1

Inline-CSS ist im Allgemeinen schlecht. Es ist viel einfacher, den Stil einer Seite zu ändern, wenn sich alle Stile an einem zentralen Ort befinden, den Inline-CSS nicht bietet. Es ist einfach für das schnelle Prototyping von Stilen, sollte aber nicht in der Produktion verwendet werden, besonders da es oft zu Duplizierungsstilen führt.

Eingebettetes CSS zentralisiert die Stile für die Seite, aber es erlaubt Ihnen nicht, Stile über Seiten hinweg zu teilen, ohne den Text des eingebetteten Stils zu kopieren und ihn in jede einzelne Seite Ihrer Website einzufügen.

External CSS ist der Weg zu gehen, es hat alle Vorteile von eingebetteten CSS, aber es ermöglicht Ihnen, Stile über mehrere Seiten hinweg zu teilen.

    
Andrew Noyes 16.03.2010 15:11
quelle
1

Verwenden Sie externes CSS, wenn:

  • Sie haben eine Menge CSS-Code, der Ihre Datei unordentlich macht, wenn Sie alles inline einfügen
  • Sie möchten einen Standard beibehalten Look-and-Feel über mehrere Seiten hinweg

Externes CSS macht es viel einfacher, Ihr CSS zu verwalten und ist die akzeptierte Methode zur Implementierung von Stilen.

Wenn die Styles nur für eine Datei benötigt werden und Sie nicht vorhersehen, dass sich diese Änderungen auf andere Seiten anwenden lassen, können Sie Ihre CSS an den Anfang der Datei stellen (eingebettet?).

Sie sollten im Allgemeinen nur Inline-CSS verwenden, wenn:

  • Es ist eine einmalige Formatierung für ein bestimmtes Tag
  • Sie möchten die Standard-CSS (extern oder am Anfang der Datei) für ein bestimmtes Tag
  • überschreiben
froadie 16.03.2010 15:11
quelle
0

Pros:

Ermöglicht Ihnen, das Layout der gesamten Site mit einer Datei zu steuern. Änderungen wirken sich auf alle Dokumente gleichzeitig aus. Kann überflüssiges Inline-Styling eliminieren (Schriftart, fett, Farbe, Bilder) Stellen Sie mehrere Ansichten desselben Inhalts für verschiedene Arten von Benutzern bereit.

Nachteile:

Ältere Browser können CSS möglicherweise nicht verstehen. CSS wird nicht von jedem Browser gleichermaßen unterstützt. In diesem Fall überwiegen die Vorteile die Nachteile bei weitem. Wenn die Site auf eine bestimmte Art und Weise entworfen wird, zeigen ältere Browser den Inhalt (im Durchschnitt) viel besser an, als wenn die Site mit Tabellen verwaltet würde.

    
Chauhan Ronak H 18.04.2013 18:13
quelle
0

Wenn Sie eine serverseitige Sprache verwenden, warum CSS nicht einbetten und bedingte Programmierung verwenden, um sie wie erforderlich anzuzeigen? Angenommen, Sie verwenden PHP mit Wordpress und Sie möchten ein CSS, das sich auf die Startseite bezieht. Sie können die Funktion is_home () verwenden, um Ihr CSS nur für diese Seite im Kopf des Dokuments anzuzeigen. Persönlich habe ich mein eigenes Vorlagensystem, das wie folgt funktioniert:

inc.header.php = all die Kopfzeilen, und wo seitenspezifische CSS gehen würde, stelle ich:

%Vor%

Dann würde ich in einer bestimmten Seitenvorlage (etwa about.php) eine heredoc Variable für das seitenspezifische CSS, über der Zeile, die den Header enthält:

Inhalt von about.php:

%Vor%

Gibt es etwas, das mir fehlt, das diesen Ansatz unterlegen macht?

Vorteile:

1) Ich kann die Seite immer noch mit Standard-Caching-Techniken zwischenspeichern (gibt es eine Caching-Methode, die eine externe CSS-Datei nutzt?).

2) Ich kann php für spezielle Fall bedingte Formatierung in bestimmten Klassen-Deklarationen verwenden, wenn absolut notwendig (PHP funktioniert nicht in einer CSS-Datei, es sei denn, ich fehlen einige Server-Richtlinie, die ich einstellen könnte).

3) All mein seitenspezifisches CSS ist extrem gut in der eigentlichen PHP-Datei organisiert, in der es verwendet wird.

4) Es reduziert HTTP-Anfragen an externe Dateien.

5) Es reduziert Serveranforderungen an externe Dateien.

Nachteile:

1) Mein IDE-Programm (Komodo IDE) kann der Heredoc-Formatierung nicht folgen, um das CSS richtig hervorzuheben, wodurch es etwas schwieriger wird, Syntaxfehler im CSS zu debuggen.

2) Ich kann wirklich keinen anderen Betrug sehen, bitte erleuchte mich!

    
James Huckabone 15.06.2013 07:19
quelle
0

An alle im Hier und Jetzt, nach 2015 lesend, mit Projekten wie Polymer , Browserify , Webpack , Babel und viele andere wichtige Teilnehmer, die ich wahrscheinlich vermisse, wurden wir in eine neue Ära des Schreibens von HTML-Anwendungen eingeführt, in Bezug darauf, wie wir große Anwendungen modularisieren, Änderungen verteilen und damit zusammenhängende Präsentationen erstellen , Markup und Verhalten in in sich geschlossenen Einheiten. Beginnen wir nicht einmal mit Service-Mitarbeitern.

Bevor sich also jemand eine Meinung darüber bildet, was machbar ist und was nicht, würde ich empfehlen, dass er das aktuelle Web-Ökosystem zu seiner Zeit untersucht, um zu sehen, ob einige Probleme im Zusammenhang mit der Wartbarkeit elegant gelöst wurden.

    
Filip Dupanović 26.11.2015 23:38
quelle

Tags und Links