Ok, in einer anderen Frage wurde etwas diskutiert, und dieser Link wurde erwähnt:
In diesem Artikel sagen sie einige Dinge, die ich nicht kannte, aber bevor ich danach frage, sollte ich das fragen ... Gilt das für CSS, das von Firefox interpretiert wird? Verzeihen Sie mein Noobness, aber ich war nicht sicher, was sie mit Mozilla UI meinten. (tu mir nicht weh!)
Wenn es zutrifft, wenn sie sagen:
Vermeiden Sie den Nachkommenselektor!
Der Nachfahren-Selektor ist am meisten teurer Selektor in CSS. Es ist schrecklich teuer, vor allem wenn a Regel mit dem Selektor befindet sich im Tag oder universelle Kategorie. Häufig was ist wirklich erwünscht ist das Kind Wähler. Die Verwendung des Nachkommens Selector ist in UI CSS ohne verbannt die ausdrückliche Genehmigung Ihrer Haut Modulbesitzer.
%Vor%
Der Nachfahren-Selektor ist nur ein Leerzeichen? Und was wäre der Unterschied zwischen Kind und Nachkomme? Kind ist ein Element in einem anderen, aber ist das nicht dasselbe wie ein Nachkomme? Während ich schreibe, denke ich, dass ich es herausgefunden habe. Ein Nachkomme könnte ein Kind / Enkel / Urenkel / etc sein? Und Kind ist nur eine Tiefe?
Entschuldigung nochmal für das blöde Niveau meiner Frage ... ich frage mich nur, weil ich ständig Nachkommen in meinem CSS für meine Seite benutzt habe. Aber wenn es nicht um Firefox geht, dann ist diese ganze Frage sinnlos ...
Wenn es nicht um Firefox geht, hat jemand einen Link zu einem Artikel, der die Effizienz für Firefox oder Browser im Allgemeinen erklärt?
Erstens - die Vorschläge in diesem Artikel sind nicht für HTML-Seiten - sie sind speziell für die Mozilla-Benutzeroberfläche - XUL Es ist vielleicht die beste Vorgehensweise für XUL, aber nicht für HTML.
Das Anwenden des CSS auf einer durchschnittlichen HTML-Seite ist eines der schnellsten Dinge, die beim Laden der Seite auftreten.
Außerdem könnte der Artikel den schnellsten Weg zur Anwendung von CSS-Regeln vorschlagen, aber um welchen Preis? Zum Beispiel schlagen sie vor, nicht mehr als eine Klasse pro Regel zu haben:
BAD - .treecell.contented {}
GOOD - .treecell-eingerückt {}
Das ist fast unverschämt . Es kann zu schnellerem CSS führen, aber wen interessiert das? Angenommen, Sie haben bereits .treecell und .indented , führt die Befolgung dieser Vorschläge zu komplizierterer Logik , härterer Wartung, duplizierten css -Regeln, härterem JavaScript (das kostet viel mehr CSS), usw.
Sie schlagen vor, nicht die ganze Fülle von CSS Selektoren zu verwenden und diese Selektoren durch flache Klassen zu ersetzen, was schade ist.
Ein Nachkomme könnte ein Kind / Enkel / Urenkel / etc sein? Und Kind ist nur eine Tiefe?
Ja genau. Da ein Kind nur eine Tiefe haben kann, gibt es viel weniger Platz, den die Rendering-Engine rekursiv durchsuchen muss, um zu überprüfen, ob die Regel übereinstimmt oder nicht.
Und ja, in diesem Artikel geht es sowohl um Firefox als auch um Browser im Allgemeinen. Die meisten (alle?) Von dem, was darin enthalten ist, gelten für jede Seiten-Rendering-Engine.
... während ich schreibe, denke ich, dass ich es herausgefunden habe. Ein Nachkomme könnte ein Kind / Enkel / Urenkel / etc sein? Und Kind ist nur eine Tiefe?
Tatsächlich.
Eine Sache, die ich auf der Effizienzseite der Dinge hinzufügen kann, ist: Benutze * nicht, es sei denn, du meinst es wirklich . Es ist ziemlich intensiv, wenn die Regeln gehen und die meisten Leute könnten wegkommen, indem sie nur die Elemente angeben, auf die sie wirklich zielen wollen.
Ein "Eltern & Kind Kind" ist nur eine Stufe tiefer, während ein "Vorfahren Nachkommen" eine oder mehrere Stufen runter sein kann.
Noch besser ist es, "#id" -Tags zu verwenden, wo immer dies möglich ist, so dass es weniger DOM-Suchen gibt.
Das CSS der Benutzeroberfläche dient zum Formatieren der Interna des Browsers - der Einstellungsdialog, Erweiterungsschnittstellen usw.
Nachkommen und Kinder sind anders, Kinder sind viel spezifischer und führen dazu, dass viel weniger berücksichtigt werden muss.
Das Problem mit dem untergeordneten Selektor ist, dass er nicht so gut unterstützt wird. Natürlich könnte dies in neueren IE-Browsern behoben worden sein.
Wenn CSS für eine Webseite geschrieben wird, wird es auf jeden Fall nicht so groß sein. Ich bezweifle, dass die Sekundenbruchteile, die Sie beim Laden der Seite sparen würden, sogar bemerkt würden. Dieser Artikel scheint mehr auf Leute gerichtet zu sein, die Sachen für den eigentlichen Browser schreiben, nicht auf Webseiten.
O'Reillys
Ich denke, es sind zwei Punkte zu beachten.
Ja, wenn Sie das so weit wie möglich tun würden, wäre Ihr HTML und CSS ein Chaos von Stilen und möglicherweise sogar ineffizienter aufgrund der hinzugefügten Dateigröße. Es liegt am Entwickler, das beste Gleichgewicht zu wählen. Ärgere dich nicht über die Optimierung jeder Zeile, während du sie schreibst, lass sie funktionieren und sieh dann, was nützlich sein kann.
Wie ein anderer Kommentator bemerkt hat, dauert es einige Millisekunden, um herauszufinden, wie Sie Ihre Stile beim Laden der Seite anwenden. Wo dies jedoch viel größere Auswirkungen haben kann, ist mit DHTML. Jedes Mal, wenn Sie das DOM ändern, wendet der Browser das gesamte Stylesheet erneut auf die Seite an. In diesem Szenario können viele ineffiziente Selektoren eine sichtbare Auswirkung auf Ihre Seite haben (wahrgenommene Nachlässigkeit / Nichtansprechbarkeit).
Die Dokumentation zu Googles Page Speed (ein Firefox / Firebug Add-on) enthält eine gute Seite auf effizientem CSS .
Tags und Links html css performance mozilla