Beiträge von Horstmann

Zitat von cityhai

Die Lösung in meinem Fall, nach dem Update des Scriptes vom 16.10.2024, war die scrollbox auf false zu setzen.
Oder den alten Eintrag "scrollbox > slot {" so zu belassen.

Deshalb auch meine Frage im ersten Beitrag, ob das jemand bestätigen kann.

Was du evtl. mal probieren könntest, ist statt scrollbox[smoothscroll="true"] > slot {... ein anderes Attribut zu benutzen, zB scrollbox[orient="horizontal"] > slot {..., an der entsprechenden Stelle im Skript.

Damit scheinen alle anderen zu arbeiten, wie Aris und Otherguy, Links zu mehr Infos hier.

Zitat von 2002Andreas

Zitat von Horstmann

war die verschwendete Zeit noch zusätzlich für die Katz.

Soll ich dich jetzt bedauern, oder was soll die Bemerkung?

Ein bisschen vielleicht?

Ich sag ja nur; viele dieser Anpassungen sind wertvolle Info auch in anderen Anwendungen, und gehen komplett unter wenn sie unkommentiert in ein Monsterskript gepflanzt werden.

Ich selber schreib auch immer fleißig mit bei solchen Detailänderungen, falls ich's mal brauchen kann, oder wie der Kollege oben ein angepasstes langes Skript habe, das ich nicht wegen einer modifizierten Zeile komplett neu aufsetzen will.

Zitat von 2002Andreas

Zitat von Horstmann

ohne dass man 100te Zeilen Code vergleichen muss

Die die das so genau wissen wollen, können das mit einem der vielen Programme, oder auch online, ohne Probleme auch mal selber machen, denn auch dadurch lernt man.

Google kannte ich eigentlich schon, also nicht's dazugelernt.

Und für die kurze Zeit, die das smoothscroll Attribut vermutlich nur relevant sein wird, v.a. in dieser obsoleten Schreibweise, war die verschwendete Zeit noch zusätzlich für die Katz.

Zitat von Mira_Belle

Zitat von lionsson

Daher würde ich gerne nur die neuen Zeilen austauschen, die die aktuelle Fehlerkorrektur betreffen.

Zeile 400, aus scrollbox > slot  { wird scrollbox[smoothscroll="true"] > slot {.

Wenn bei Gelegenheit solche kleinen Änderungen von Vornherein kurz beschrieben würden, ohne dass man 100te Zeilen Code vergleichen muss, könnte tatsächlich mal jemand etwas davon lernen...

Zitat von Firefox_94.0.1

Ich habe jetzt noch eine ganz seltsame Beobachtung gemacht: egal, welches Theme ich einstelle: nach einem neuen Öffnen von Firefox ist der schwarze Rahmen wieder da. Das Problem ist daher (leider) doch noch nicht gelöst...

Also, wenn du zB das helle Firefox Theme eingestellt hast, und der Rand ist weg, und dann Fx beendest - das helle Theme ist jetzt immer noch unverändert aktiv - und neu startest, ist der schwarze Rand wieder da?

Zitat von 2002Andreas

Zitat von Horstmann

und ist nur auf transparent gesetzt

Das meine ich ja, er ist nicht sichtbar.

Darum hatte ich ihn ja auch nach seinem Theme gefragt.

Ah, verstehe, dann fragen wir ja nach dem Gleichen.

Wie erwähnt, evtl. spielen OS spezifische Einstellungen noch mit rein, aber es wäre tatsächlich vor allem gut zu wissen, wie das Ganze beim OP mit dem System Theme und/oder den eingebauten Fx Themes aussieht.

Zitat von 2002Andreas

Zitat von Firefox_94.0.1

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.

Zitat von 2002Andreas

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.

Zitat von Firefox_94.0.1

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;.

Zitat von Persephone

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.

Zitat von Endor

Endor

Zitat von 2002Andreas

Zitat von Sören Hentzschel

Zitat von Mira_Belle

Zitat von Boersenfeger

Dankeschön !!!

Zitat von 2002Andreas

---

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.

Zitat von Sören Hentzschel

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..

Zitat von grisu2099

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.

Zitat von 2002Andreas

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....

Zitat von Sören Hentzschel

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...

Zitat von Sören Hentzschel

Mit der Ergänzung funktioniert der Code auch in Firefox Nightly:

CSS

slot {
  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.

Zitat von Boersenfeger

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.

Zitat von milupo

Genauso ist es, scrollbox sitzt hier in einem shadow-Dingens, korrekt: Es befindet sich unter shadow-root. Auch erkennbar am Attribut part. Da musst du dann schon das Skript userChromeShadow.uc.js zusammen mit der userChromeShadow.css verwenden. Die Variable nutzt dir hier m. E. nichts, weil scrollbox dann dennoch unter shadow-root liegt. Auch mit Variable greifst du ja auf scrollbox unter shadow-root zu.

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.

Zitat von milupo

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...