als Bild z.B. PNG oder ICO oder sowas.
Teste bitte, Icons und Pfad musst du dann anpassen.
#star-button {
list-style-image: none !important;
}
#star-button[starred="true"] {
background-image: url("file:///C:/Users/Andi/Icons%20Firefox/Benutzer.gif") !important;
background-repeat: no-repeat !important;
background-position: 0px 0px !important;
background-size: 15px 15px !important;
}
#star-button:not([starred="true"]) {
background-image: url("file:///C:/Users/Andi/Icons%20Firefox/ClassicTRoptions.ico") !important;
background-repeat: no-repeat !important;
background-position: 0px 0px !important;
background-size: 15px 15px !important;
}was wäre denn jetzt besser
Der kurze Pfad ist dann richtig, wenn du im Ordner chrome den Unterordner Icon hast.
Bei mir ist das nicht in allen Profilen so, darum der längere Pfad.
Welches Format vom Icon besser ist kann ich dir nicht sagen, ich nutze alle.
ich hätte mal eine Frage zu den Pfad der Bilder.
Ich bastel ja nu auch ne ganze Menge an meinem "Goldbärchen-Outfit" herum und bin froh, daß ich über den relativen Pfad
../icons/diesunddas.png alle benötigten GFX immer automatisch mitsichere, wenn ich den Profil-Ordner backuppe.
Aber das ist nur mein persönlicher Weg 
Für .css klappt das mit dem Pfad so ganz gut - für .js hab ich mir im TB-Forum eine andere Lösung zur Ermittlung des aktuellen Pfades abgucken müssen - aber das ist eine andere Geschichte
ok es ist ja egeal ob es PNG, ICO oder sonst was ist, was wäre denn jetzt besser ?
Ich mach das davon abhängig, was ich finde und wie sich die GFX verhalten soll - nicht bei allen Formaten kann man eine
transparente Hintergrundfarbe einstellen, wenn es opportun wäre.
Just my 2¢
ok es ist ja egeal ob es PNG, ICO oder sonst was ist, was wäre denn jetzt besser ?
Je kleiner die Dateigröße, desto besser. Also wenn du dich schon für ein Pixelformat wie PNG entscheidest, dann kannst du auch WebP oder AVIF verwenden. Ansonsten lassen sich auch PNG- und JPEG-Grafiken häufig ohne Qualitätsverlust signifikant in ihrer Dateigröße reduzieren. Ich nutze dafür das Tool ImageOptim, aber das gibt es nur für macOS. Für Windows gibt es aber mit Sicherheit vergleichbare Tools.
Für ICO fällt mir in diesem Zusammenhang ehrlich gesagt gar kein Argument ein. Das Format hat auch seinen Anwendungsfall, aber der besteht nicht in Firefox-Anpassungen. Die Stärke von ICO ist eigentlich die Möglichkeit, dass es mehrere Grafiken beinhalten kann.
Ansonsten ist das Vektorgrafik-Format SVG natürlich immer dankbar, da es ohne Qualitätsverlust skalieren kann (was dir kein Pixelformat bieten kann) und je nach Anwendungsfall auch Anpassungen via CSS möglich sein können. Für die Größen-Optimierung von SVG-Dateien verwende ich üblicherweise das Online-Tool https://jakearchibald.github.io/svgomg/.
Ich mach das davon abhängig, was ich finde und wie sich die GFX verhalten soll - nicht bei allen Formaten kann man eine
transparente Hintergrundfarbe einstellen
Eine Konvertierung in andere Bildformate wäre ja auch kein Hexenwerk. Dafür nutze ich XnConvert. Das gibt es für Windows, macOS und Linux. Das kann zwar noch kein AVIF, aber immerhin WebP, was ja auch schon ein großer Gewinn ist.
Die Möglichkeit für einen transparenten Hintergrund ist natürlich ein guter Punkt, aber damit fällt letztlich von den gängien Pixelformaten nur JPEG raus.
Die Stärke von ICO ist eigentlich die Möglichkeit, dass es mehrere Grafiken beinhalten kann.
In Abhängigkeit von Darstellung als Größe. Ansonsten beinhaltet animiertes GIF oder PNG auch mehrere Grafiken, wobei der Zweck ein anderer ist. Transparenter Hintergrund, GIF mit entsprechende Farblimitierungen, PNG oder auch transparentes BMP. WEBP hier direkt erstellen ist mir nicht möglich, würde ich aber auch für den Einsatz daheim nicht unbedingt als erste Option nutzen wollen deswegen.
Hat es einen speziellen Grund, warum du xnconvert nutzt und nicht direkt xnview, welche (gibt ja zwei) diese Möglichkeiten auch bieten?
Unterschiedliche Frames einer Animation würde ich jetzt nicht unbedingt als mehrere Grafiken beinhalten bezeichnen, denn letztlich wird ja unter allen Voraussetzungen immer die gleiche Bildfolge angezeigt. Jedenfalls habe ich diesen Vorzug auch nur deswegen hervorgehoben, weil es das einzige Argument ist, welches mir überhaupt für dieses Format einfällt. Oder anders formuliert: Für Firefox-Anpassungen würde das Format in meinen Überlegungen gar keine Rolle spielen.
Wenn man WebP nicht direkt erstellen kann, macht es ja nichts. Eine anschließende Konvertierung bringt den gleichen Vorteil: eine deutlich reduzierte Dateigröße.
XnView gibt es nur für Windows und ist damit keine Option für mich. Mit XnView MP, was es auch plattformübergreifend gibt, hat das Programm außerdem einen Nachfolger (auch wenn die Classic-Version wohl nach wie vor Updates erhält). Theoretisch würde XnView MP wohl auch gut dafür funktionieren. Aber der Fokus ist bei dem Programm schon noch das Betrachten von Bildern, wie der Name ja auch sagt. Da ich XnConvert ausschließlich für die Konvertierung verwende, sagt mir die Oberfläche von XnConvert, die den Fokus eben auch auf die (Batch-) Verarbeitung legt, dafür einfach mehr zu.
Danke.
eine deutlich reduzierte Dateigröße.
Auch für so kleine Grafiken wie hier?
Wenn du mir eine Beispiel-Grafik zeigen kannst, kann ich schauen, wie viel das ausmacht.
Ich kann dir nur das wenige anbieten, was ich aus Aris seiner Sammlung nutze, das ist überschaubar, obwohl ich nicht alle Symbole bisher gesehen habe, oder nur betriebsblind war. Die Bildchen sind fast alle <1kb
Oder sowas
https://www.camp-firefox.de/attachment/33638-pasted-from-clipboard-png/
Als base64
(der Haufen Symbole im Menü)
Am Beispiel der ersten Grafik aus dem Anhang, bookmarksMenu.png:
PNG-Datei: 307 Bytes
PNG-Datei optimiert mit ImageOptim: 259 Bytes
Als WebP-Datei umgewandelt mit XnConvert: 234 Bytes
24% kleiner, klingt viel, aber 73 Bytes sind jetzt kein Quantensprung, vor allem, wenn ich an die Sektor-Belegung auf der Festplatte denke. 512 Bytes pro Sektor, und das ist noch klein, ich hab Platten hier, die haben 4096 Bytes/Sektor. Also der Slack ist schon heftig dort. Danke für den Test.
Über das Thema habe ich auch schon öfter nachgedacht. Die paar Byte Größenunterschied wirken sich wohl eher überhaupt nicht aus. Eher interessant fände ich, welches Format resourcenschonender in der Anzeige ist bzw. den besten Kompromiß zwischen Größe und Rechenaufwand für Decodierung und Anzeige bietet.
Am allerliebsten würde ich ja eigentlich die Icon-Definition in der Art: resource://gre/chrome/toolkit/skin/classic/global/icons/xxxxx.svg verwenden. Leider scheint das auch eine Spielwiese der Mozilla-Bastler zu sein und man kann sich nicht darauf verlassen, daß der Link in der nächsten Version noch aufgelöst wird. Zig Icons sind doppelt und mehrfach vorhanden, nutzlose Graphiken dazu, aber eine Version später fehlt gerade das, was man braucht...
Dem stimme ich nicht zu, dass sich das überhaupt nicht auswirken würde. Knapp ein Viertel Ersparnis ist nicht wenig. Vor allem, da es meistens ja doch um weit mehr als nur ein einziges Icon geht und dann möglicherweise sogar in mehreren Fenstern. Und die Grafiken wollen dann alle und für jedes Fenster im Speicher gehalten werden. Ich spreche dabei nicht vom Platz auf der Festplatte respektive SSD, weil das vorher erwähnt wurde, sondern von den dekodierten Bilddaten im RAM. Außerdem war das jetzt nur an einem Icon gemessen, ein anderes Icon mag weniger Ersparnis bringen, ein anderes Icon dafür umso mehr. Ich sehe das ja oft, wenn ich Grafiken erhalte, dass ich alleine durch die PNG-Optimierung teilweise auch mal 90 Prozent einer Dateigröße wegbekomme. Man kann diesen Wert nicht pauschalisieren. Von praktisch gar nichts bis fast alles ist alles möglich. Und mit einem anderen Dateiformat sowieso. Natürlich kann man immer streiten, was nun der Wert von solchen "Micro-Optimierungen" ist. Aber die Frage, die ich mir dann stelle, ist die: Die Optimierung respektive Konvertierung ist ein Aufwand von wenigen Sekunden, bringt ein nachweisbares Ergebnis und hat keinen einzigen Nachteil. Welchen Grund hätte man also, das nicht zu tun, wenn man denn weiß, dass diese Möglichkeit besteht?
Und jetzt mal noch weiter gedacht: Wenn die Grafiken dann auch noch hier im Forum oder anderswo geteilt werden: Mit kleineren Grafiken tut man dann auch was für die Umwelt: Kleinere Dateigrößen bedeuten weniger CO2-Emissionen. Da macht selbst 1 KB schon richtig viel aus. Mal etwas Lektüre zu diesem Thema:
Eher interessant fände ich, welches Format resourcenschonender in der Anzeige ist bzw. den besten Kompromiß zwischen Größe und Rechenaufwand für Decodierung und Anzeige bietet.
Für die Decodierung gibt es keinen nennenswerten Unterschied zwischen JPEG, PNG und WebP.
Am allerliebsten würde ich ja eigentlich die Icon-Definition in der Art: resource://gre/chrome/toolkit/skin/classic/global/icons/xxxxx.svg verwenden. Leider scheint das auch eine Spielwiese der Mozilla-Bastler zu sein und man kann sich nicht darauf verlassen, daß der Link in der nächsten Version noch aufgelöst wird.
Ich weiß zwar nicht, was die Formulierung "Spielwiese der Mozilla-Bastler" sein soll, da Mozilla sein Produkt mal sicher nicht als Spielzeug betrachtet und Spielerei und Bastelei ja wohl eher Begriffe sind, die für diese individuellen Anpassungen durch Nutzer treffend wären. Aber natürlich kann man sich nicht darauf verlassen, dass etwas, was heute funktioniert, auch zwei Versionen später noch funktioniert. Das hat allerdings damit, wie du Icons einbindest, wenig zu tun. Selbst wenn sich an der Grafik selbst nichts ändert, kann sich das relevante CSS respektive HTML entscheidend verändern und benötigt dann Anpassungen. Das ist eben das Risiko solcher individuellen Anpassungen. Es ist aber auch nicht so, dass sich ein und dieselbe Stelle mit jedem Update wieder verändern würde.
Zig Icons sind doppelt und mehrfach vorhanden, nutzlose Graphiken dazu, aber eine Version später fehlt gerade das, was man braucht...
Wie kommst du darauf, dass es "nutzlose Grafiken" geben würde? Und wenn dir wirklich "nutzlose Grafiken" bekannt sind, wäre das ja ein ziemlich leichter Patch, den du beitragen könntest.
Abgesehen davon ändert sich so viel jetzt auch nicht daran. Ja, im Rahmen des Proton-Redesigns wurde da einiges angepasst und vereinheitlicht. Aber es ist jetzt auch nicht so, dass permanent Pfade angepasst oder Icons entfernt würden. Jedenfalls geschieht keine Änderung nur der Änderung wegen, sondern jede Änderung aus Gründen. Wenn man sich von Interna abhängig macht, muss man eben entsprechend am Ball bleiben. Das ist nur logisch. Es ist halt auch nicht so gedacht, dass man sich von irgendwelchen internen Icon-Pfaden abhängig macht.
