Die horizontale Ausrichtung der Schrift im Tab soll immer mittig sein, also weder unten, noch oben; wie läßt sich das bewerkstelligen?
oder habe ich das falsch verstanden?
Sieh und staune.
Und deine Tab CSSs, ehrlich gesagt - bitte nicht.
Die horizontale Ausrichtung der Schrift im Tab soll immer mittig sein, also weder unten, noch oben; wie läßt sich das bewerkstelligen?
oder habe ich das falsch verstanden?
Sieh und staune.
Und deine Tab CSSs, ehrlich gesagt - bitte nicht.
Du müsstest deine Anpassungen teilen, damit man dazu mehr sagen kann.
Ebent; könnte auch eher in das Anpassungen Forum passen.
Zum Tabinhalt, was mir gerne mal in die Quere kommt ist die leicht übersehbare fixe Höhe vom .tab-label-container, wenn man die Tabs-relevanten Dimensionen ändern möchte.
Ob das hier eine Rolle spielt, kann man ohne den Code vom OP nicht sagen.
Ich hab den Stilcode jetzt auf das aktuelle Theme eingeschränkt, das geht zum Glück, weil es im Style-Attribut eingetragen ist. Bei manchen sehr hellen Themes sind weiße Schalter sowieso schlecht bis gar nicht zu erkennen. Dann muss ich den Teil in Testprofilen eben anpassen, wenn nötig.
Es gibt auch noch Provisorien für zB light-dark, wenn du das mal bei searchfox eingibst, und ähnliches (nur für's Prinzip, ist alt), um zwischen System/hell/dunkel Themes zu unterscheiden, und eine Menge Variablen.
Wie man sowas aber sauber implementiert ist zu hoch für mich.
Im Zweifel kann man immer mal bei Aris, MoG oder auch Godie nach Lösungen stöbern.
Oups, nm.
Ich hätte grob geraten, basierend darauf ... in deinem alten JS:
Zeile 25 undoCloseTab(0); => undoCloseTab(window, 0);.
Evtl. noch Zeile 73 undoCloseTab(id); => undoCloseTab(window, id).
Ist aber wohl veraltet.
Danke für den Code. Damit werden sie zwar wieder weiß, jedoch habe ich dann immer noch das Problem, dass sich die Farbe bei :hover nicht wie vorgesehen verhält. Die Schaltflächen solllen im Normalzustand zwar alle weiß sein, bei :hover sollen sie jedoch die Farbe auf schwarz ändern, da man sie sonst aufgrund der definierten (und noch funktionierenden) Hintergrundfarben dann nicht mehr erkennt.
Am besten immer den ganzen aktuellen Code einstellen.
Mein Verdacht wäre, das du den Code von Speravir and deinen alten angehängt hast, dann würden vermutlich deine Hover Codes damit überschrieben. An meinem Mac sind diese Buttons anders angelegt, kann ich also nicht testen.
Kannst mal testen, eine Variante von Speravir's Code:
Oder gesamt evtl. sowas:
/* Icon Farben ändern */
#main-window .titlebar-buttonbox .titlebar-button {
color: #fff !important;
}
/* Mouse-over Farbe ändern */
#main-window .titlebar-buttonbox .titlebar-button:hover {
border-radius: 5px !important;
color: black !important;
}
/***** links *****/
#main-window .titlebar-min:hover{
background:#66FF66!important; /*Farbe: hellgrün*/
}
/***** mitte *****/
#main-window .titlebar-max:hover {
background:#FFFF00!important; /*Farbe: gelb*/
}
#main-window .titlebar-restore:hover {
background-color:#FFFF00!important; /*Farbe: gelb*/
}
/***** rechts *****/
#main-window .titlebar-close:hover {
background:#FF0000!important; /*Farbe: rot*/
}
Alles anzeigen
Hängt aber sehr warscheinlich mit dem anderen CSS zusammen.
Sollte mir angewöhnen auf meine eigenen Ratschläge zu hören!
Immer den Ganzen Code, wobei...
Habe ich nicht hier ds komplette Skript ...CSS Alles anzeigen/* ----------------------------------- */ /* -- Checkbox und Haken im Submenu -- */ /* ----------------------------------- */ menuitem[checked="true"] > .menu-iconic-left { list-style-image: url("${ProfilePath}/check.svg"); fill: #00E400 !important; } [data-l10n-id="toolbar-context-menu-bookmarks-toolbar-always-show-2"]:not([checked="true"]), [data-l10n-id="toolbar-context-menu-bookmarks-toolbar-on-new-tab-2"]:not([checked="true"]), [data-l10n-id="toolbar-context-menu-bookmarks-toolbar-never-show-2"]:not([checked="true"]), #menu_zoomReset:not([checked="true"]), #toggle_zoom:not([checked="true"]), #menu_pageStylePersistentOnly:not([checked="true"]) { background-image: url("${ProfilePath}/square.svg"); background-repeat: no-repeat; } [data-l10n-id="toolbar-context-menu-bookmarks-toolbar-always-show-2"]:not([checked="true"]) > label[value="Immer anzeigen"], [data-l10n-id="toolbar-context-menu-bookmarks-toolbar-on-new-tab-2"]:not([checked="true"]) > label[value="Nur bei neuem Tab anzeigen"], [data-l10n-id="toolbar-context-menu-bookmarks-toolbar-never-show-2"]:not([checked="true"]) > label[value="Nie anzeigen"] { margin-left: -25px; }
Ach was solls, es funktioniert ja.
Du hast Icons mit drin, das wäre schon gut gewusst zu haben...
Und am besten bitte Screenshots beifügen, die die Probleme zeigen bzw auch wie's aussehen soll, ich bin mir immer noch nicht sicher was das gewünschte Ergebnis ist.
Übrigens, bei mir habe ich die Check Haken in den Kontextmenüs nach rechts verfrachtet mit order: , sieht für mich sauberer aus; den Code dafür für aktuelles Fx und Windows kann ich dir aber leider nicht anbieten.
Ok, hier was zum Testen; mal die Farb-Otionen durchprobieren, im Anhang ein Icon ohne context-fill im SVG Code als Vergleich zu den Standard Fx Icons, das context-fill ja idR hat; auch Hover probieren:
.bookmark-item[container] {
/*list-style-image: url("icons/YourFolderIcon-ohne.svg") !important;*/
color: cyan !important;
fill: red !important;
}
#bookmarks-menu-button .toolbarbutton-text {
display: flex !important;
}
#bookmarks-menu-button {
/*list-style-image: url(icons/YourFolderIcon-ohne.svg) !important;*/
color: cyan !important;
/* fill: red !important;
-webkit-text-fill-color: purple !important; */
}
Alles anzeigen
Wenn der Code nicht im .svg enthalten ist kann das css den entsprechenden Code einfügen.
Nein.
CSS kann nur - falls nötig - einem Element die Fähigkeit den im .svg enthaltenen Code zu benutzen hinzufügen (-moz-context-properties), oder eben via fill/stroke etc. diesen enthaltenen Code manipulieren - falls context-etc. im .svg gesetzt ist.
Und wie in deinem Script enthalten, muss in wenigen Fällen auch svg.context-properties.content.enabled gesetzt werden.
CSS kann aber nichts in einen .svg Code hinein schreiben.
Und wie gesagt, color zu setzen kann Nebenwirkungen haben, deshalb ist currentColor oft keine Lösung.
Könntest Du diese Aussage präzisieren?
Color wird in Fx für alles Mögliche benutzt, für Text natürlich, dann oft für den Hintergrund, oder auch nur für Hover, und eben auch für farblich undefinierte .svgs, via diversen internen Codes.
Der Punkt ist, dass man die .svg Iconfarbe innerhalb eines Elements nicht trennen kann von dem oben erwähnten potentiellen Einfluss den CSS color allgemein hat, wenn man fill/stroke etc. nicht konkret im .svg definiert - oder eben im .svg fill="context-fill" (etc.) einträgt, um dann via CSS separat darauf zugreifen zu können.
Dann dürften aber in Fx CSS sowohl fill als auch fill-opacity nicht mehr funktionieren, oder?
Warum testest Du es nicht einfach selbst und postest dann hier die Antwort?
Es war nicht wirklich eine Frage, wollte nur höflich auf deinen Irrtum hinweisen.
Ohne context-fill etc. sind svg icons nicht vollständig Fx kompatibel.
Und wie gesagt, color zu setzen kann Nebenwirkungen haben, deshalb ist currentColor oft keine Lösung.
Nur bei den Checkboxen unter Ansicht/Symbolleisten/Lesezeichen-Symbolleiste... bekomme ich es einfach nicht hin!
Und dann wäre da nur noch ein :nth-child... im CSS (Code) welches ich auskommentiert habe.
Kann wohl zukünftig weg.
Andreas ist mir zuvorgekommen, die Dinger haben ihre eigene ID.
Statt negativen Margins würde ich selber aber immer erstmal das Element anschaunen - deshalb hat uns Baby Jesus ja die Browser Werkzeuge gegeben - und evtl. padding-left: 0 !important; setzen, dann schauen ob 4px noch fehlen.
Edit: altes FX und Mac, aber kannst ja mal testen:
[data-l10n-id="toolbar-context-menu-bookmarks-toolbar-always-show-2"]:not([checked="true"]) {
padding-left: 4px !important;
color: cyan !important;
}
[data-l10n-id="toolbar-context-menu-bookmarks-toolbar-on-new-tab-2"]:not([checked="true"]) {
padding-left: 4px !important;
color: blue !important;
}
[data-l10n-id="toolbar-context-menu-bookmarks-toolbar-never-show-2"]:not([checked="true"]) {
padding-left: 4px !important;
color: red !important;
}
Alles anzeigen
entferne ich immer den Code
fill-opacity:context-fill-opacity; aus dem Icon.Danke für den Tipp! Funzt das auch, wenn du fill:context-fill;fill-opacity:context-fill-opacity; komplett entfernst (Bin auf Linux; deshalb die Frage)? Und funzt das mouseover im Script dann trotzdem?
Dann dürften aber in Fx CSS sowohl fill als auch fill-opacity nicht mehr funktionieren, oder?
Und color, falls es als Ersatz dienen kann, sollte man mE eher sparsam benutzen.
Dass context-xxx in svg Code nur begrenzt mit dem OS harmoniert ist bekannt, aber svgs müssen ja nur mit Fx kompatibel sein.
Schau noch mal
Schau auch nochmal => hier, und darüber und darunter.
Und noch ein Vorschlag: alles mit :nth-child... vermeiden, das ist OS abhänging und ändert sich dauernd.
Weiss nicht genau wie das Script im Detail funktionieren soll, aber geht sowas?
// Undo Close Tab Test
(function() {
if (!window.gBrowser) return;
try {
CustomizableUI.createWidget({
id: 'uc_undo_closetab_button',
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let toolbaritem = aDocument.createXULElement('toolbarbutton');
let props = {
id: 'uc_undo_closetab_button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
label: 'Undo Close',
tooltiptext: 'Undo Close Tab',
style: 'list-style-image: url(chrome://global/skin/icons/reload.svg)',
};
for (let p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { }
document.getElementById('uc_undo_closetab_button').addEventListener('click', event => {
if (event.button === 0) {
undoCloseTab();
}
});
})();
Alles anzeigen
Ich verwende General padding. Relative Pfad- oder Ressourcen Icons.
Yup, genau sowas.
Nur benutzt es kein Padding, aber das ist Semantik.
Ich vermute das ist nur ein Ausschnitt aus deinem Kontextmenü Code, korrekt?
Würde mich sehr interessieren was du mit --content-type anstellst, ich kann die Variable nicht im aktuellen Firefox Code finden.
Für die Icons sollte eigentlich auch sowas klappen, und damit für diverse OS (?):
/*background-image: url("..//icons//paste16.png"); ==> */
background-image: url("icons/paste16.png");
Das wäre dann für den icons Ordner im gleichen Ordner wie die CSS Datei.
Mein ganzes CSS für Kontextmenü Symbole sind fast 6000 Zeilen.
Willst Du Dir die wirklich im ernst antun?
Hier mal ein ausschnitt davon:
Oje...
Und also doch extra Code im Spiel?
In den meisten Fällen kann man Basiscode für bestimmte Elemente einmal zusammengefasst eingeben, via den allgemeinen IDs, Tags, Classes und evtl. übergeordneten Elementen zur Eingrenzung.
Zentral gesammelt aufbauen, evtl. ein paar Variablen dazu, und das Troubleshooting wird unendlich einfacher.
Ich war schon lange nicht mehr in den Kontextmenüs unterwegs, aber mehr als eine Handvoll Basiselemente/Klassen relevant für die Icons wird's vermutlich nicht geben.
Spezifische Einträge, für einzelne Schaltflächen, braucht es nur für das Icon an sich, alles andere macht keinen Sinn zu wiederholen, oder wie von Dejavu erwähnt mehrfach und unterschiedlich aufzubauen.
Im Zweifel immer mal bei Aris oder MOG reinschauen, wie die sowas angehen.
Was dir im Moment nicht weiterhilft, aber das sieht aus wie ein Fall von suboptimalem CSS plus altersbedingter Codeblähung.
Wobei das mit dem ; padding-left: 36px;} eben die Fehlerkorrektur ist!
Was man für alle betroffenen Elemente entweder als Variable anlegen, oder besser noch einmal direkt festlegen kann.
Wenn sich mehrere solcher wiederholten Regeln über 1000de Zeilen Code ziehen, auch für nur wenige Elemente die leicht unterschiedlich gehandhabt werden müssen, dann hat man Ärger vorprogrammiert.
Hallo zusammen.
In Firefox 141 beta da sind fast überall die Abstände im Kontextmenü
bei den Symbolen zum Text wieder richtig im Vergleich zu Firefox 140.
Nur aus Neugier: meinst du einen generellen Firefox Bug, oder entsteht das Problem im Zusammenhang mit eigenen CSS Codes, JS Scripts, oder Erweiterungen?
Aber wieso Schweiz? Das interessiert mich wirklich, denn bei mir klingelt da nichts.
Mist, Österreich sollte das heissen!
direkte Bildanhänge im Forum werden bei mir generell als webp Dateien angezeigt, die funktionieren nur in der Schweiz.
Was genau ist der Zusammenhang zwischen WebP und der Schweiz?
Nur ein kleiner Scherz bzgl. irgendeiner Konversation die wir mal hatten über webp Umwandlung im Forum und allgemeine weitere Nutzbarkeit, weiss nicht wo oder warum ich mich daran erinnere.
Jetzt ist alles gut.
Prima!
Fyi: direkte Bildanhänge im Forum werden bei mir generell als webp Dateien angezeigt, die funktionieren nur in der Schweiz.