Iconabstände in Urlbar-Container verkleinern

Zitat von BarbaraZ-

die Abstände dazwischen verringert?

Teste bitte, und pass dir den Wert wenn dann an.

toolbar .toolbarbutton-1 {
  margin: 0px -5px !important;
}

oder meinst du diese Button?

Wenn, dann:

#star-button-box,
#translations-button,
#reader-mode-button {
  margin-right:  -7px !important;
}

Zitat von BarbaraZ-

Danke schön.

Freut mich wenn ich dir damit helfen konnte, war gern geschehen

Zitat von 2002Andreas

Zitat von BarbaraZ-

die Abstände dazwischen verringert?

Teste bitte, und pass dir den Wert wenn dann an.

CSS

toolbar .toolbarbutton-1 {
  margin: 0px -5px !important;
}

CSS

#star-button-box,
#translations-button,
#reader-mode-button {
  margin-right:  -7px !important;
}

An dieser Stelle würde ich dann doch mal gerne Folgendes einwerfen: negative Margins sind generell ein no-no; Fx benutzt sie hier und da für spezielle Anwendungen, ich selber auch zur Not wenn gar nichts mehr geht, aber so gut wie nie.

Es ist auch völlig unnötig bei Buttons und in Toolbars; eine einfache aber faule Lösung, die das Layout und Funktionen schnell durcheinander bringen kann und wird.

Zitat von Horstmann

negative Margins sind generell ein no-no

Nicht zwingend. Es ist nicht immer schön, aber als Pauschalaussage unterschreibe ich das nicht. Das muss man situativ bewerten. Welche konkrete Alternative schlägst du in diesem Fall vor? Du musst ja eine bessere Alternative haben, wenn du das schreibst. Dann wäre es zielführend, diese auch zu teilen.

Zitat von Sören Hentzschel

Nicht zwingend. Es ist nicht immer schön, aber als Pauschalaussage unterschreibe ich das nicht. Das muss man situativ bewerten. Welche konkrete Alternative schlägst du in diesem Fall vor? Du musst ja eine bessere Alternative haben, wenn du das schreibst. Dann wäre es zielführend, diese auch zu teilen.

Dass es Aunahmen geben kann hatte ich schon erwähnt.

Hier ein kleines Experiment:

toolbar .toolbarbutton-1 {
    margin: 0px -5px !important; 
    outline: 1px solid red !important;
    outline-offset: -1px !important;
}
toolbar .toolbarbutton-1 image {
    outline: 1px solid green;
    outline-offset: -1px !important;  
}

Die Buttons überlappen sich bzw. ragen auch in andere Elemente hinein, an einigen Stellen kann es an den Übergängen daher zum Flackern der beteiligten Elemente kommen.
Auch mal Tab Overflow testen damit, flackert bei mir.

Man darf bei den Buttons nicht vergessen, dass idR. der Button an sich nicht gesamt sichtbar ist, sondern nur der Inhalt und dessen Hintergrundfarben, Outlines etc..
Aktiv als Schaltfläche is aber der gesamte Button, hier .toolbarbutton-1.

Die visuellen horizontalen Abstände kommen dann (nicht alle) vom Padding innerhalb der Buttons, soweit ich sehe durch die Variable --toolbarbutton-outer-padding, die ich aber nicht anfassen würde.

Ergo würde ich in diesem Fall so etwas zum Testen vorschlagen, hier nur für die angefragte Navbar:
(Nachtrag: irgendwas ist doch immer mit den verdammten Buttons)

#nav-bar .toolbarbutton-1 {
    padding-inline: 0px !important;
}
#nav-bar .toolbaritem-combined-buttons {
    margin-inline: 0px !important;
}

/*Nachtrag*/
#nav-bar #PanelUI-menu-button {
  padding-inline-end: var(--toolbar-start-end-padding) !important;
}
#nav-bar-customization-target > :is(toolbarbutton, toolbaritem):first-child,
  #nav-bar-customization-target > toolbarpaletteitem:first-child > :is(toolbarbutton, toolbaritem) {
    padding-inline-start: var(--toolbar-start-end-padding) !important;  
}

Die -1px extra bei Andreas, wohl um Outlines hübscher aufeinander zu legen, scheinen laut Screenshot im Originalbeitrag nicht nötig zu sein, da keine permanente Outline um die Buttons ist.

Screen vom bösen Code:

Zitat von Sören Hentzschel

Welche konkrete Alternative schlägst du in diesem Fall vor? Du musst ja eine bessere Alternative haben, wenn du das schreibst. Dann wäre es zielführend, diese auch zu teilen.

Du verstehst jetzt vielleicht, warum man hier nicht immer den Aufwand betreiben möchte, um in ein Thema zuviel zu investieren.
Das wäre Grund #1, #2 wird sicher prompt geliefert.

Eine Diskussion wäre mir lieber gewesen, aber so würde ich nun ernsthaft vorschlagen, dass der Code aus diesem Beitrag entfernt wird.
Ich denke er ist fehlerhaft, und verursacht signifikante Probleme.

Zitat von Horstmann

Du verstehst jetzt vielleicht, warum man hier nicht immer den Aufwand betreiben möchte, um in ein Thema zuviel zu investieren.
Das wäre Grund #1

Auf welcher Grundlage soll ich das verstehen beziehungsweise wo steht „Grund #1”?

Mir ging es nur grundsätzlich darum, dass man nicht einfach nur sagen sollte, dass eine Lösung schlecht ist, sondern dann auch eine bessere Lösung oder zumindest einen Ansatz zur Lösung liefern. Das hast du dann gemacht. Damit hatte ich das Thema für mich ehrlich gesagt als erledigt betrachtet, da ich selbst an dieser Anpassung ja überhaupt nicht interessiert bin.

In Fx 135 wurde für Addon-Buttons eine zusätzliche Ebene im DOM eingeführt, die anscheinend für deren zusätzlichen Abstände verantwortlich ist, und zwar eine
<box class="unified-extensions-item-row-wrapper">.

Ich hab jedenfalls erstmal für mich diese Regel ergänzt:

.unified-extensions-item-row-wrapper {
	margin-inline: -2px !important
}

(Genau genommen ein wenig anders, aber das spielt hier jetzt keine Rolle.)

Horstmann, Andreas hat Barbara darum gebeten, seinen Vorschlag zu testen, und sie war zufrieden damit. Ich verstehe Deine Ausführungen nicht. Wenn ein Website-Designer mit negativen Werten arbeiten muss, dann ist das schlechter Stil, wobei es sein kann, dass er ein vorgefundenes Framework nur auf diese Weise übersteuern kann. Wenn ein Privatmensch für sich etwas ändert, dann sehe ich nicht, wo das Problem sein soll.

Die wenigen Ausnahmen in Firefox für margin und Kompagnons sind nach einer Schnellsuche übrigens 742 Funde in 169 CSS-Dateien; eventuell per Javascript eingefügte negative Abstände sind dort nicht enthalten.

Zitat von Speravir

In Fx 135 wurde für Addon-Buttons eine zusätzliche Ebene im DOM eingeführt, die anscheinend für deren zusätzlichen Abstände verantwortlich ist, und zwar eine
<box class="unified-extensions-item-row-wrapper">.

Ich hab jedenfalls erstmal für mich diese Regel ergänzt:

CSS

.unified-extensions-item-row-wrapper {
	margin-inline: -2px !important
}

(Genau genommen ein wenig anders, aber das spielt hier jetzt keine Rolle.)

Die wenigen Ausnahmen in Firefox für margin und Kompagnons sind nach einer Schnellsuche übrigens 742 Funde in 169 CSS-Dateien; eventuell per Javascript eingefügte negative Abstände sind dort nicht enthalten.

Ich weiss nicht was in deinem Fall das Problem mit den Erweiterungs-Buttons ist, und ob Aris Code da mit reinspielt, aber soweit ich das sehe sind die Abstände in Fx135 nicht über diese Box geregelt (s. auch Screenshots unten, in Kompaktmodus).
Sieht so aus als hätte der .toolbarbutton-1 innerhalb des .toolbaritem-combined-buttons jetzt ein Padding, weiss aber nicht seit welcher Version das sein könnte.

Und was für eine Suche wo hat so viele negative Margins gefunden?

Was - grob in Fx135 getestet, in Normal- und Kompaktmodus - klappen sollte ist das von oben; das wäre jetzt für 0 Abstand zwischen den Buttons:

#nav-bar .toolbarbutton-1 {
    padding-inline: 0px !important;
}
#nav-bar .toolbaritem-combined-buttons {
    margin-inline: 0px !important;
}

Und dann eben noch die Anpassungen aus dem Nachtrag, zumindest für den Menübutton; das negative Margin ist auch hier mE unnötig, und macht den gleichen Ärger wie das gehabt.

Zitat

Andreas hat Barbara darum gebeten, seinen Vorschlag zu testen, und sie war zufrieden damit. Ich verstehe Deine Ausführungen nicht. Wenn ein Website-Designer mit negativen Werten arbeiten muss, dann ist das schlechter Stil, wobei es sein kann, das er ein vorgefundenes Framework nur auf diese Weise übersteuern kann. Wenn ein Privatmensch für sich etwas ändert, dann sehe ich nicht, wo es Problem sein soll.

Wie erklärt, sehe ich keinen Grund für, aber potentielle Probleme durch die negativen Margins.
Recht zu haben ist mir wumpe, ich halte nur den Code für nicht korrekt.
Ich denke es ist nur fair für alle User darauf hinzuweisen; für Gegenargumente bin ich immer offen, und natürlich liege ich auch öfters mal falsch.

Ein kurzer Blick in die Browsertools, und man sieht welcher Abstand wie erzeugt wird.
Das dann sauber zu manipulieren ist aufwendiger, durch die diversen Button und Leisten Designs.

Natürlich kann jeder sowieso machen was er/sie will, und wer keine Probleme darin sieht Elemente wild zusammen und übereinander zu schachteln, inkl. Schaltflächen, der kann das natürlich auch gerne tun.

Zitat von Speravir

In Fx 135 wurde für Addon-Buttons eine zusätzliche Ebene im DOM eingeführt, die anscheinend für deren zusätzlichen Abstände verantwortlich ist, und zwar eine
<box class="unified-extensions-item-row-wrapper">.

Ich hab jedenfalls erstmal für mich diese Regel ergänzt:

CSS

.unified-extensions-item-row-wrapper {
	margin-inline: -2px !important
}

(Genau genommen ein wenig anders, aber das spielt hier jetzt keine Rolle.)

Könnte sein dass hier das Problem mit den Erweiterungsbuttons in der Toolbar liegt; in Zeile 161/162 ist zwar wie gehabt der Code vorhanden um das normale Padding von .toolbarbutton-1 zu überschreiben (2px bzw. 3px für Kompakt), aber wie du entdeckt hast ist .unified-extensions-item-row-wrapper dazwischen, vermutlich wird daher der Codeteil nicht ausgeführt.

Also spezifisch in deinem Fall könnte das klappen:

toolbar .toolbaritem-combined-buttons > .unified-extensions-item-row-wrapper > .toolbarbutton-1 {
    padding-inline: 0 !important;
}