Nur die Anzeige der Ordner/Lesezeichenanzahl in einer anderen Farbe darstellen

    Zitat von Horstmann

    ZB ist opacity: 0.5 deutlicher langsamer als etwa color: hsl(0, 0%, 50%, 0.5) !important; und fill: hsl(0, 0%, 50%, 0.5) !important;.

    Dass der Unterschied für dich wahrnehmbar ist, finde ich ein wenig überraschend in Anbetracht dessen, um wie wenige Elemente es eigentlich geht. Aber grundsätzlich ist es nicht überaschend, dass opacity langsamer ist, weil sich das auf sämtliche Eigenschaften auswirkt und das andere eben nur auf color und fill. Außerdem verändert opacity nicht nur die Deckkraft für das Element selbst, sondern auch für sämtliche Kindelemente. Das ist also mit wesentlich mehr Arbeit für den Browser verbunden.

    Zitat von grisu2099

    Man könnte die "Nuller" auch einfach ausblenden... ;)

    Mach ich doch auch in den Codebeispielen, für den ersten Ordner Zähler - aber wenn ein Ordner keine Lesezeichen drin hat, aber Ordner - dann will ich den Ziffern Zähler nur verblasst haben! ;)



    Etwas anal, ich weiss, aber einfach kann jeder.
    Den aktuellen Code habe ich übrigens auch angepasst, um wahlweise einen oder beide 0 Zähler mit display: none ausblenden zu können, wie du es bei dir gemacht hast, ohne weitere Änderungen, also flexibler als vorher.
    So zumindest der Plan, bin schon ganz verunsichert nach meinen ganzen Pannen. ;)

    Zitat von Sören Hentzschel

    Dass der Unterschied für dich wahrnehmbar ist, finde ich ein wenig überraschend in Anbetracht dessen, um wie wenige Elemente es eigentlich geht. Aber grundsätzlich ist es nicht überaschend, dass opacity langsamer ist, weil sich das auf sämtliche Eigenschaften auswirkt und das andere eben nur auf color und fill. Außerdem verändert opacity nicht nur die Deckkraft für das Element selbst, sondern auch für sämtliche Kindelemente. Das ist also mit wesentlich mehr Arbeit für den Browser verbunden.

    Bin auch überrascht, aber es passiert deutlich merkbar nur bei vielen Einträgen mit opacity in einem einzelnen Popup.

    In diesem Fall ist das mein - wenig realistischer - Test Setup im Testprofil, der teils Dutzende Lesezeichenordner mit keinen Ordnern und/oder keinen Lesezeichen drinnen hat; also eine Menge Pseudoelemente mit opacity < 1.

    Deine Erklärung macht auch Sinn; ich kenne es aus mehreren (Render) Anwendungen, daß Transparenz teils massive Leistungseinbrüche mit sich bringen kann, wenn sie nicht sehr gezielt/lokalisiert eingesetzt wird.

    Einmal editiert, zuletzt von Horstmann (24. April 2025 um 17:40) aus folgendem Grund: Ein Beitrag von Horstmann mit diesem Beitrag zusammengefügt.

    Ein grosser Unterschied wäre noch die Möglichkeit, separate CSS Dateien live editieren und speichern zu können in den Browser Werkzeugen, und auch sofort ein Ergebnis zu sehen.

    Damit kann man über mehrere verbundene CSS Dateien parallel arbeiten, idealerweise mit einer zentralen Kontroll CSS plus darin importierten CSS Dateien für grössere Varianten, und dabei alle Styling Elemente aufeinander abstimmen ohne Restarts etc..

    Ausserdem fällt damit ein Menge zusätzlicher Code weg im JS, das ganze Dateipfad Gedöns und die Einbindung von CSS allgemein, was bei Fx Code Veränderungen das eventuelle Troubleshooting weiter kompliziert.

    Horstmann Stimmt, das sind durchaus Punkte, die für ein ausgelagertes CSS sprechen.

    Für CSS im Skript spricht "für" mich, es ist variabler.
    Mann hat alles unter "Dach und Fach", und wenn man geschickt die Variablen setzt,
    hat man so etwas wie ein Konfigurationsbereich, wie ich schon mit dem Hinweis auf das Scrollbar-Skript beschreiben wollte.
    Auch hat man mit JavaScript Möglichkeiten, die einem nur in CSS so nicht so einfach, oder auch gar nicht, zur Verfügung stehen.

    Für einen Benutzer ist ein JavaScript, so denke ich, in der Anwendung einfacher, er muss nicht mehrere Dateien in verschiedene
    Verzeichnisse ablegen.
    Die Konfiguration des Skriptes, wenn geschickt gemacht, sollte auch für einen Laien einfach sein, weil er ja dann,
    nichts am eigentlichen Code verändern muss und brauch.

    Nachteil, es werden Monster, wenn man alles Mögliche abdecken will.
    Kann man ja hier in diesem Thread mit "meinem" Skript nachvollziehen.
    Hatte das ursprüngliche Skript ca. 150 Zeilen,
    hat die letzte funktionierende Version schon ca. 200 Zeilen.

    Ich finde Javascript einfach spannend und in Kombination mit CSS steht einem der Firefox offen.
    Ob nun Funktionen und Layout getrennt oder, wie ich es lieber mag, Funktionen und Layout kombiniert in einer Datei,
    ist wohl eine Frage der persönlichen Vorlieben. Denke ich.

    Was sagt DIhr dazu Sören Hentzschel und BrokenHeart ?
    Interessiert mich, bitte einen kleinen Kommentar.

    Mit <3lichem Gruß

    Mira

    Zitat von Mira_Belle

    Was sagt DIhr dazu Sören Hentzschel und BrokenHeart ?
    Interessiert mich, bitte einen kleinen Kommentar.

    Es kommt immer darauf an, was man möchte.

    Ich bin grundsätzlich dagegen, Dinge zu vermischen, die nicht zusammen gehören. Weder CSS noch JavaScript gehört in HTML-Dateien und CSS gehört auch nicht in JavaScript-Dateien. Denn das verhindert eine effektive CSP, es erschwert Linting und man bekommt noch nicht einmal Syntax-Highlighting für die „fremde“ Sprache. Für die Wartbarkeit und damit letztlich auch Code-Qualität ist das schlecht.

    Wenn einem das egal und dafür wichtiger ist, möglichst alles mit einer einzelnen Datei teilen zu können, sind das halt andere Voraussetzungen.

    Aber als kleiner Inspirations-Ansatz, weil eine Konfiguration angesprochen worden ist: Das eine sind CSS-Variablen. Damit kann man schon viel anpassbar machen. Und wenn man größere Abhängigkeiten benötigt, könnte man im Script eigene Optionen in about:config setzen. Diese kann man dann im CSS wiederum auslesen. Auf diese Weise kann man if/else-Kontrukte auch im CSS simulieren.

    Zitat von Sören Hentzschel

    Es kommt immer darauf an, was man möchte.

    So schaut's aus.

    Dein Einwand kann ich durchaus verstehen, wenn man große Projekt pflegt,
    wie den Onlineauftritt eines Unternehmens würde es auf jeden Fall sehr schnell unübersichtlich und kompliziert werden.

    Wir reden hier aber nur von kleinen Anpassungen des Firefox. ;)

    Und man muss auch bedenken, dass weniger visierte Anwender solche Anpassungen vornehmen möchten.
    Einige sind ja schon fast überfordert, die richtigen Vorbereitungen zu treffen, damit der Firefox überhaupt anpassbar wird.

    Nun bin ich gespannt, was BrokenHeart zu dem Thema meint.

    Eventuell trenne ich in Zukunft ja doch CSS und JavaScript, aber ich weiß es noch nicht.

    Mit <3lichem Gruß

    Mira

    Zitat von Mira_Belle

    Nun bin ich gespannt, was BrokenHeart zu dem Thema meint.

    Habe eigentlich keine dezidierte Meinung dazu, sehe das so ähnlich wie du. Bei der hier üblichen Größe spielt es wohl keine große Rolle, ob man sein CSS auslagert oder direkt im Skript verwurstet. Aber übertreiben sollte man es wirklich nicht mit dem eingebundenen CSS - so wie ich es bei den MultiRowTabs gemacht hatte :(.

    Bei größeren (professionellen) Projekten hat Sören sicher mit seinen Hinweisen recht.

    Mich interessiert die Thematik aber nicht sonderlich, da ich die Beschäftigung mit den "Formalismen" von JavaScript/CSS nicht so wichtig finde. Für mich steht das Verstehen des Firefox-Quellcodes im Vordergrund: z.B. die Aufrufe über die idl-Schnittstelle und die Funktionalität aus den importierten Modulen. Was nützt es mir mit sauberem Code "in Schönheit zu sterben", wenn ich nichts über die Firefox-spezifischen Möglichkeiten von CSS/Javascript weiß und das auch anwenden kann?:/

    OT: Viel wichtiger finde ich, dass endlich mal jemand (zumindest für Windows) ein (PowerShell-)Skript schreibt, welches das Herunterladen und Entpacken der zum Ausführen von User-Skripten notwendigen Dateien übernimmt. Ich kenne mich leider nicht mit dem Scripting aus und eine ausführbare Anwendung in C++ zu schreiben halte ich für übertrieben. Außerdem hat man nachher eine .exe Datei, die auch noch mit Administrator-Rechten ausgeführt werden muss. Auch wenn man Quellen und make-File mitliefert, kann ich jeden verstehen, der so was nicht nutzen möchte. Ein Skript wäre da schon geschmeidiger.

    Ich bin mir sicher, wenn so ein Skript existiert, würden auch mehr Menschen die User-Skripte nutzen.

    Mira_Belle Du beherrscht das doch, wenn ich mich nicht täusche. Na, wie wär's ...:P

    Gruß BrokenHeart

    "success has many fathers, failure is an orphan"

    Zitat von BrokenHeart

    Du beherrscht das doch, wenn ich mich nicht täusche. Na, wie wär's ... :P

    Würde ich ja gerne, aber so wirklich fit bin ich da auch nicht!
    UND wäre auf jeden Fall auf Hilfe angewiesen.
    Und dann wäre ja noch das Problem mit dem Testen!!
    In einer VM sollte das kein Problem sein, aber bisher habe ich auf meinem System
    es einfach noch nicht hinbekommen, so ein Ding zu starten. Ums verrecken nicht!
    Da steh' ich mir wohl selbst im Weg, warum auch immer.


    Nachtrag!

    Ich überrasche mich immer mal wieder selber!
    ABER ich scheitere am Profilpfad.

    Runterladen, ok. Entpacken, ok.
    Kopieren der "config.js" ins Programmverzeichnis, auch ok,
    Anlegen des Ordners "userChromeJS", auch kein Ding.
    Kopieren der Dateien, die da rein sollen, abgehakt.

    Und dann kommt das Profilverzeichnis:!:
    Ende. Da verließen sie sie! Ich bin in einer Schaffenskrise. ^^


    "$env:APPDATA "Mozilla\Firefox\Profiles" bis hier her komme ich, und dann "xxx..default"!?
    Ich muss ja in diesen Ordner um darin den "chrome"-Ordner erstellen zu können.

    Jemand eine Idee?

    Mit <3lichem Gruß

    Mira

    Einmal editiert, zuletzt von Mira_Belle (26. April 2025 um 10:01)

    Zitat von Horstmann

    Ein grosser Unterschied wäre noch die Möglichkeit, separate CSS Dateien live editieren und speichern zu können in den Browser Werkzeugen, und auch sofort ein Ergebnis zu sehen.

    Geht wohl fast hiermit:

    Mit Spannung erwartet, hier meine aktuelle Version, damit ich das Ding endlich aufhöre weiter zu bearbeiten. ;)

    Hoffe es macht Sinn; Kommentare und Aufbau für Bedienbarkeit zu gestalten ist immer eine Herausforderung.
    Es ist noch Einiges an Variablen enthalten; wer diese oder einige Varianten nicht braucht, kann wo nötig feste Werte eintragen bzw. Letztere löschen.

    Wir hätten hier Icons von Firefox, ersetzbar mit eigenen Icons (zB die im Anhang), eine entfernbare Trennlinie, und eine Option die Reihenfolge von Icon und Zahlenwert umzukehren, plus einige mögliche kosmetische Anpassungen.
    Das ganze sollte sich ohne viel Drama automatisch für die diversen Varianten anpassen lassen über die Basiseinstellungen. :/

    Test und Kritik wie immer herzlich willkommen. :)

    icons.zip

    Nur, wenn Du möchtest!!

    Du könntest oben Variablen definieren, die die Einstellung für das Klammergedöhns vereinfachen,
    und niemand müsste im Code groß was verändern.
    Einfach eine "0" für ohne, eine "1" für runde oder eine "2" für eckige Klammern.

    Und das mit der Trennlinie ließe sich auch so lösen.
    "0" keine, "1" eine Trennlinie, ginge auch mit true & false.

    Aber ist nur so eine Idee und muss ja auch nicht sein.
    Finde Dein Skript gut. :thumbup:

    Mit <3lichem Gruß

    Mira

    Zitat von Mira_Belle

    Du könntest oben Variablen definieren, die die Einstellung für das Klammergedöhns vereinfachen,
    und niemand müsste im Code groß was verändern.
    Einfach eine "0" für ohne, eine "1" für runde oder eine "2" für eckige Klammern.

    Danke Mira. :)

    Das mit den Klammern als JS Option würde evtl. Sinn machen, da müsste ich mich aber nochmal einlesen wie das geht (viele deiner früheren Postings zu JS Variablen kenne ich auch).

    Ich wollte nur ein Mittelding finden zw. Variablen und manuell, so daß das CSS möglichst übersichtlich bleibt, und Styles weitmöglichst im CSS Block sitzen, für User die sich darüber ihr eigenes Ding basteln wollen.

    Vorschlag.

    JavaScript
        // Variable zur Auswahl der Klammern
    let out = 0; // 0 für "ohne Klammern", 1 für "runde Klammern", 2 für "eckige Klammern"

    und ganz unten dann:

    Mit <3lichem Gruß

    Mira

    Einmal editiert, zuletzt von Mira_Belle (18. Mai 2025 um 14:51)

    Zitat von Horstmann

    PS: Ab Fx 139 sollte das alte Script nicht mehr funktionieren, und evtl. kommen dann Anfragen und weitere Kommentare; ...

    Nach Belieben veränder, zerpflücken und anpassen, funktioniert in der Nightly.

    Mit <3lichem Gruß

    Mira