Ankündigung

Einklappen
Keine Ankündigung bisher.

Reihenfolge der css Dateien

Einklappen
X
Einklappen
 
  • Seite von 1
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige template Weiter
    #1

    Reihenfolge der css Dateien

    Ich hätte da eine Anregung zum Aufbau vom <head>.
    Wenn es nicht irgendeinen wichtigen Grund für die aktuelle Reihenfolge der css Einbindungen gibt, den ich gerade übersehe, dann würde ich vorschlagen, die basic.css und custom.css als letzte einzubinden.
    Mir ist gestern aufgefallen, dass ich manche Angaben z.b. bei gweather nicht ändern kann, weil die gweather.css im Nachhinein alles wieder überschreibt.
    Klar, kann ich die Änderung auch in der gweather.css vornehmen. Wenn ich jedoch ein Design erstelle, möchte ich natürlich, dass es bei anderen Nutzern genauso aussieht auch ohne dass dieser selber noch etwas in den plugins ändern muß.

    Christian
    Stichworte: -
    #2
    Hallo,

    das sollte eigentlich auch so sein. die Plugin-CSS sind defaults, wenn das Design nichts anderes sagt und custom überschreibt das Design, weil der User es explizit will.

    Im Augenblick wird von der Template-Engine zuerst designglobals.css, dann basic.css des Designs, dann mobile.css des Designs und danach custom.css eingebunden. Das ist soweit m.E. auch richtig und gut. Allerdings werden die Plugins erst danach geladen, was dazu führt, dass das CSS des Plugins weiter unten steht.

    Wenn nichts dagegenspricht, würde ich die Reihenfolge ändern.

    Gruss,

    der Jan
    KNX, DMX over E1.31, DALI, 1W, OpenHAB, MQTT

    Kommentar

      #3
      IMHO würde diese Reihenfolge den meisten Sinn machen:
      1. Gobales
      2. Design allgemeines
      3. Mobil
      4. alle Plugins
      5. Lokales / Persönliches
      TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

      Kommentar

        #4
        Ich würde 4. an 2. Stelle setzen, weil ich denke ein Plugin kann ein "default Aussehen" haben. Könnte es das nicht, müsste jeder Plugin-Schreiber gleich die CSS für jedes Design anpassen.

        Das Plugin ist aber halt nur Code, wenn ein Design-Ersteller möchte, dass es anders aussieht, dann sollte er das ändern können.

        Als Beispiel rsslog-Plugin: Es gibt ein relativ dezentes default im Plugin-CSS, aber in pitchblack ist das umdefiniert. Das geht aber nur in der anderen Reihenfolge.

        Und natürlich, wenn der Anwender noch was anderes will, dann sollte das oberste Priorität haben.

        Aber: Da hängt nicht mein Herzblut dran.

        Gruss,

        der Jan
        KNX, DMX over E1.31, DALI, 1W, OpenHAB, MQTT

        Kommentar

          #5
          Sehe ich aber auch so.
          Das plugin css sollte vom Design (also basic.css) verändert werden können und vom Nutzer durch das custom.css am Ende.
          So kann der Pluginersteller eine Vorlage geben damit es erstmal funktioniert, der Designersteller kann es an das Design anpassen und der Nutzer am Ende wieder alles verwerfen

          Kommentar

            #6
            Die Idee dahinter war, dass ein Plugin manchmal ein Default übersteuern können muss.

            Aber da bei CSS ja das spezifischere noch vor der Reihenfolge gewinnt (IIRC), dann sollte Position 2 auch universell passen können.

            (Und sollte ich mich hier irren, könnte man notfalls 2 CSS für Plugins zulassen. Aber diese Option würde ich ohne Not nicht ziehen wollen)
            TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

            Kommentar

              #7
              Ja, spezifischer gewinnt vor Reihenfolge.

              Gruß,

              der Jan
              KNX, DMX over E1.31, DALI, 1W, OpenHAB, MQTT

              Kommentar

                #8
                Das ganze ist etwas komplizierter, als ich eigentlich dachte. Die Plugins werden asynchron geladen, es reicht nicht das Laden der Design-CSS hinter das Parsen des Plugin-Teils zu schieben. Und es gibt insgesamt drei Stellen, von denen eventuell weiter gesprungen wird, wenn die Plugins fertig sind.

                Nachdem ich das dreimal eingefügt hatte, wurde komischerweise nur noch ein Teil der Visu angezeigt. Es ist offensichtlich so, dass das append des Design-CSS noch nicht abgeschlossen ist, wenn setup_page aufgerufen wird. Vorher war das vermutlich immer der Fall, weil das Laden der Plugins länger gedauert hat.

                Das kann man mit einem window-Timeout unterbinden, bei MIR reicht 1 ms sowohl im FF als auch im Chrome, aber ich bin mir nicht völlig sicher, ob das generell so ist. Das birgt ganz deutlich die Gefahr von schwer reproduzierbaren Fehlern, abhängig von der Browser-Geschwindigkeit. Auf der anderen Seite verzögert ein "sicheres" grosses Timeout den Seitenaufbau deutlich.

                Und nu? Man könnte da vielleicht noch folgendes tricksen: Interne Stylesheets haben priority vor externen (behaupten zumindest die meisten Hits bei google, ich habs im Standrad aber nicht gefunden. Man könnte die design/custom-css als inline laden und die plugin-CSS als extern. So auf den ersten Blick scheint das bei mir zu funktionieren.

                Gruss,

                der Jan
                KNX, DMX over E1.31, DALI, 1W, OpenHAB, MQTT

                Kommentar

                  #9
                  Zitat von JNK Beitrag anzeigen
                  Und nu?
                  Wird's wohl Zeit das ganze Thema sauber zu engineeren.

                  Denn es wird komplexer: nicht nur die CSS Reihenfolge ist wichtig, die JS Reihenfolge auch. Und die wird ja inzwischen beim Build-Prozess dynamisch angefasst.
                  Und noch schlimmer: ich hebe gelesen, dass man den Script-Elementen inzwischen ein Asynchron-Attribut mitgeben kann, was sich positiv auf die Lade-Geschwindigkeit auswirken soll (=> Haben will!) - aber die große Gefahr von Nicht-Determinismus bietet.

                  => Jemand freiwilliges der das ganze Konzept mal durchdenken und implementieren möchte?
                  TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                  Kommentar

                  Vorherige template Weiter
                  Lädt...
                  X

                  Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.

                  Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.

                  Ich stimme zu