der Rahmen ist trotzdem da:
Standard gibt es den nicht.
Doch.
Diese Outline gibt es schon seit einiger Zeit, und jetzt immer noch; sie war und ist nur auf transparent gesetzt für die meisten Anwendungsbeispiele, ist aber permanent vorhanden.
Outline, nicht border 
; im Code sichtbar, aber nicht in der Layoutdarstellung in den Tools.
Besser wäre doch erstmal zu klären, woher der Rahmen bei ihm überhaupt kommt. Standard ist der nämlich nicht. Und dazu müsste er mal seinen kompl. Code hier posten.
Hier am Mac erscheint die Outline, wenn man in seinen OS Einstellungen Kontrast erhöhen einstellt.
Im oben verlinkten searchfox Code sieht man noch weitere Variablen für nicht transparente Outlines bei selektierten Tabs.
Ist zwar etwas anders aufgebaut als in meinem alten 115esr , aber das Prinzip scheint noch das Gleiche zu sein.
Weshalb bei Firefox_94.0.1 der Rahmen erst nach einem Update aufgetaucht ist - keine Ahnung; der Code dafür ist allerdings generell in Fx vorhanden.
Kann tatsächlich sein dass ein anderer CSS Code für Outlines dazwischenfunkt, oder evtl. ein nicht aktuelles Theme benutzt wird.
Jetzt hat der aktive Tab aber seit heute? einen schwarzen Rahmen. Wie kann ich den entfernen? Die Ergänzung "background-color" mit der gleichen Farbe wie der Hintergrund hat nichts gebracht.
Falls das oben dein einziger Tabs Code ist (?), könntest du mal das hier testen; die selektierten Tabs haben eigentlich keine Border, sondern eine Outline:
.tab-background:is([selected], [multiselected]) {
outline-color: red !important;
/*--tab-selected-outline-color: transparent !important;*/
}Weitere Variablen und Code dazu hier und hier; evtl. hilft ja sowas --tab-selected-outline-color: transparent !important;.
Ja, dann nehme ich alles zurück und behaupte das Gegenteil. Ich ging davon aus, dass damit das viereckige Symbol (Alle Tabs auflisten) auch verschwinden würde.
Und wenn du vorab erklären würdest, was es ist wovon du ausgehst daß es magischerweise verschwände, dann könnten andere Leute dir direkt helfen, statt mühsam zu versuchen Gedanken zu lesen.
Zum Thema padding:
Außerdem besagt padding: 0, dass der Wert 0 in alle Richtungen geht.
Ergo gehört padding-top dann da nicht dahin.
Man kann schon beides benutzen, wie padding: 20px !important; gefolgt von
padding-top: 45px !important; , man muß dann halt die Reihenfolge beachten.
Effizienter und evtl. Resourcen schonender wären vermutlich die Herangehensweisen wie in deinem Link beschrieben.
Da ich macOS nutze und auf macOS die nativen Kontextmenüs des Betriebssystems genutzt werden, die nicht via CSS angepasst werden können, kann ich in diesem Fall keine Hilfe geben, das gezielter anzusprechen.
Geht zumindest in 115esr noch : widget.macos.native-context-menus in about:config auf false, und los-stylen.
Hier und da braucht's glaub ich noch appearance: none !important; im CSS Code, ist aber ne Weile her daß ich das für mich umgebaut hatte..
Momentan sehe ich einfach keinen Sinn darin, diese Baustelle anzugehen. Wie Sören ja weiter oben schon ausgeführt hat, ist in dem ganzen Bereich dermaßen viel Bewegung, das es sich einfach nicht lohnt dort Anpassungen vorzunehmen.
Macht Sinn; bzgl. will keiner 
, ich hatte damit eher die Kollegen angesprochen, die eine Lösung für mittige Tabs angefragt hatten, und dann nicht mal den angebotenen Code testen.
Es funktionieren beide Codes.
Bleibt nur die Aussage von Sören, es für die Zukunft besser per Shadow.css zu erstellen.
Danke für den Test!
Die Codevariante mit den Margins ist ja direktes CSS, ohne Umwege in die shadow-root oder dran vorbei, ich denke daher braucht's keine Shadow.css etc..
Deinen Code würd ich gerne testen, hab aber den Franken Mac mit aktuellem Fx schon wieder auseinandergebaut....
Ich denke nicht, dass dieser Umweg einen großen Mehrwert bietet. Zur Erklärung möchte auf eine grundsätzliche Gefahr bei diesem Ansatz aufmerksam machen: Eine nicht definierte Variable kann zu unerwarteten Resultaten führen, weil dann eben nicht der Wert greift, der an anderer Stelle, in dem Fall also im originalen CSS der Firefox-Oberfläche, definiert ist, sondern der Standard-Wert, wie er in der CSS-Spezifikation definiert ist.
Das ist ein sehr guter Punkt, das Problem hatte ich auch schon vor mir ...
Bei überschaubarem und einzel testbarem Einsatz von bestimmten Elementen kann man das über einen Alternativwert halbwegs regeln, oder der Defaultwert passt zufällig; aber bei etwas wie slot wird's unübersichtlich.
ZB hatte ich ursprünglichscrollbox[orient="horizontal"] {justify-content: var(--ug_tabs_position, initial) !important;} in Gebrauch, weil ich zu der Zeit nur noch eine andere horizontale scrollbox im Code finden konnte (in der Lesezeichenleiste), und die hat damit noch gepasst.
Aber jetzt mit den vertikalen Tabs und allem...
Davon abgesehen, der andere Code mit den Automargins wäre viel einfacher für das spezielle Anliegen; aber wenn's keiner testen oder benutzen will...
Mit der Ergänzung funktioniert der Code auch in Firefox Nightly:
CSSslot { display: contents !important; }Nur ist das halt sehr unspezifisch und ich weiß nicht, an welchen Stellen sich das ggf. negativ auswirkt. Ich empfehle hier wirklich dringend, den Weg über userChromeShadow.uc.js zu gehen und den Code spezifischer zu schreiben, damit sich das nur in der Tableiste auswirkt.
Ich habe mal kurz meinen Franken-Mac mit Nighly 131 angeworfen, da scheint das Prinzip mit dem Variablen Umweg auch für slot zu greifen.
#tabbrowser-tabs:not([overflow], [orient="vertical"]) {
--ug_tabs_position: center;
--ug_slot_display: contents;
}
scrollbox {
justify-content: var(--ug_tabs_position) !important;
}
slot {
display: var(--ug_slot_display) !important;
}Der Vollständigkeit halber müsste sowas auch noch funktionieren für mittige Tabs:
#tabbrowser-tabs:not([overflow], [orient="vertical"]) .tabbrowser-tab:nth-child(1 of :not([pinned], [hidden])) {
margin-left: auto !important;
}
#tabbrowser-tabs:not([overflow], [orient="vertical"]) #tabbrowser-arrowscrollbox-periphery {
margin-right: auto !important;
}Damit sind dann nur die nicht gepinnten Tabs und der Plus Button mittig.
Nur ganz kurz in der Nightly getestet, die Bedienung ist eine Qual am Franken Mac, mit einem OS auf externer Platte.
Ich wäre auch verbunden, wenn die Nebendiskussion über "Shadow-Dingens" woanders weitergeführt würde, auch das Design von Scrollbuttons ist für mich nicht relevant. Danke!
Eine Option für das Ansprechen deiner Tabs ist für dich aber relevant, was der Sinn der Diskussion war.
Du musst nicht kapieren wie das alles funktioniert, aber solltest dann evtl. nicht entscheiden wollen was relevant ist und was nicht.
Genauso ist es, scrollbox sitzt hier in einem shadow-Dingens,
Der Code funktioniert in der Form, die Variable greift auch in der relevanten shadow-root, jedenfalls bis 115esr; das Script braucht man hier nicht.
Das ist praktische Erfahrung, keine Theorie.
Ich hab den Trick schon oft benutzt, um ::part Gedöns zu manipulieren; meine Vermutung wöre eher, daß sich inzwischen im Fx Code ein paar Funktionen innerhalb der Hierarchie verlagert haben, oder Attribute geändert/hinzugefügt wurden.
Sowas könnte zB noch funktionieren:
#tabbrowser-tabs {
--ug_outline: 4px solid red;
}
#scrollbutton-up,
#scrollbutton-down {
outline: var(--ug_outline, 4px solid cyan) !important;
outline-offset: -2px !important;
}Damit sollten die Scrollbuttons im Tab overflow rot umrandet sein, aber zB in einem überlaufenden Ordner in der Lesezeichenleiste cyan.
Nimmt man #tabbrowser-tabs { --ug_outline: 4px solid red;} raus, sollten alle scrollbuttons cyan umrandet sein.
Bei mir tut sich da nichts. Und dürfte sich m. E. auch nicht viel tun. Du definierst --ug-tabs-position für #tabbrowser-tabs:not([overflow]) und nur dafür. Du verwendest es aber nicht dafür. Dann wendest du --ug-tabs-position auf scrollbox[orient="horizontal"] an, für das --ug-tabs-position gar nicht definiert ist. Im allgemeinen definiert man eine CSS-Variable unter :root, so, wie du es in deinem von mir verlinkten Code mit --ug-tab-gap gemacht hast. Dann gilt die Variable für alle Elemente.
Danke für's Testen!
Wie von Sören schon erklärt, die Variable wirkt auf die Child Elemente; die Begrenzung auf #tabbrowser-tabs:not([overflow]) soll die Auswirkung der Regel auf eben diesen Bereich eingrenzen, weil ansonsten andere scrollbox Elemente mit angesprochen würden.
Das hat unerwünschte Konsequenzen, wie auch in der von dir verlinkten Thread weiter unten erwähnt.
Ich halte Variablen generell meistens so begrenzt wie möglich, weil die einem sonst auch mal anderorts in die Quere kommen können.
Der Umweg über die Variable deshalb, weil scrollbox in einem shadow Dingens (Fachbegriff) sitzt, und nicht Jeder den Umweg über Javascript gehen möchte oder kann.
Schade daß es nicht klappt; ich kann momentan hier nur durch den Code auf searchfox stöbern und dann raten...
... es funktioniert i:M. nichts.
Hast du den Code von oben denn mal getestet?
Nochmal:
#tabbrowser-tabs:not([overflow]) {
--ug_tabs_position: center;
}
scrollbox[orient="horizontal"] {
justify-content: var(--ug_tabs_position, initial) !important;
}Firefox kennt allerdings auch keine Variable, die so benannt ist, und dein CSS verwendet die Variable auch nicht.
...denn er hat im Code-Kasten hinter diesem Link schon zwei --ug-Variablen, unter ihnen obige, verwendet:
Danke für's finden!
Hab ich oben schon was dazu geschrieben; testen kann ich leider nicht in der Nightly, weil auf 115esr... 
--ug benutze ich für meine eigenen Variablen, um sie von den oft verwendeten --uc Variablen unterscheiden zu können; es sind so oder so Fremdvariablen (nicht von Fx).
Moin, habe mal wieder ein CSS-Problem:
Seit gestern funktioniert nachfolgender CSS bei mir im Nightly nicht mehr:
CSS/* Tabs in Tableiste mittig */ #tabbrowser-tabs:not([overflow="true"]) { --ug_tabs_position: center; } scrollbox[smoothscroll="true"] { display: flex !important; justify-content: center !important ; }
Ich kann von hier aus nur raten; aber erstmal wird die Variable --ug_tabs_position in deinem geposteten Code nirgends angewendet, und zum anderen versteh ich nicht ganz weshalb du das Attribut [smoothscroll="true"] benutzt.
Kannst evtl. mal das spasseshalber testen:
#tabbrowser-tabs:not([overflow]) {
--ug_tabs_position: center;
}
scrollbox[orient="horizontal"] {
justify-content: var(--ug_tabs_position, initial) !important;
}CSS/* Tabs in Tableiste im Zentrum beginnend */ scrollbox:not(#PlacesToolbarItems) { -moz-box-pack: center !important; }
-moz-box-pack gibt's schon lange nicht mehr...
Entweder es klappt per CSS und "fill: red !important;"
Oder aber, und auch da hilft Dir dann "fill", Du öffnest die SVG mit einem Editor
und schaust nach!
Suchst den Eintrag fill="context-fill" und änderst diesen z.B. in fill="#00FF00", das wäre lime
oder fill="#ff1500" das wäre rot.
In den SVGs aus dem Internet ist aber meistens nicht fill="context-fill" enthalten, sondern eine Farbe oder currentColor, jedenfalls meiner Erfahrung nach.
fill="context-fill" muss aber in der .svg Datei stehen, damit man via CSS in Firefox drankommt; das gleiche gilt auch für stroke, stroke-opacity etc.; hier ein Beispiel aus Firefox.
Dann auch hier ein alter Beitrag zum Thema, der noch halbwegs passen könnte.
In manchen Bereichen muss man die properties für das Element freischalten, v.a. für eigene Icons, wie von 2002Andreas beschrieben; ich hatte es auch schon, daß ich zusätzlich svg.context-properties.content.enabled auf true setzen musste, in about:config, weil einige Menüs sonst nicht reagiert haben.
Wir hatten das hier mal ausführlich diskutiert, finde aber grade den Thread nicht.
Stimmt, der verändert Vieles nicht, aber den generellen Hintergrund der Zeile - was ursprünglich die Frage war, glaub ich.
Der color Teil ist bei mir allerdings nutzlos, das ist korrekt, hatte ich nur mitkopiert.
Wenn wir aber kleinlich sein wollen, dann sollte man sich evtl. auch noch der Iconfarbe annehmen.
Hg und Schriftfarbe:
Schon wieder zeitgleich fast das Gleiche gepostet.
Great minds think alike, und so.