Hallo alle,

ich habe ein Ausrichtungsproblem in einem Grid. In Firefox ist es sauber, in Chrome nicht.

Demo (ohne Anspruch auf vollständiges HTML):

<fieldset><legend>Edit</legend>
<label>Das ist ein mehrzeiliges Label:</label>
<input type="number" value="4711">
<label>Short Label:</label>
<input type="number" value="815">
<label>Das ist ein mehrzeiliges Label:</label>
<input type="text" value="Text 4711">
<label>Short Text-Label:</label>
<input type="text" value="Text 815">
</fieldset>

fieldset {
  display: grid;
  grid-template-columns: 9em 1fr;
  align-items: last baseline;
  font-size: 1em;
  row-gap: 1em;
}

Ja, die Labels sollen neben den Inputs sein und nicht darüber. Das ist Requirement und kann nicht (mehr) diskutiert werden.

In Firefox sind die Label-Texte auf der gleichen Baseline wie die Eingabewerte in den Inputs. In Chrome auch, solange die Labeltexte einzeilig sind. Für längere Labeltexte ist gewünscht, dass der Text in den Eingabefeldern mit der letzten Labelzeile fluchtet. Das geht mit align-items: last baseline.

Hier schießen aber number-Eingabefelder in Chrome quer. Die sind höher als Textfelder und der Wert im Feld befindet sich ein paar Pixel über der Label-Baseline. Das Fiddle in der problematischen Seite demonstriert das. In Firefox ok, in Chrome nicht.

Ich habe im Netz Hinweise gefunden, dass man ::-webkit-outer-spin-button und ::-webkit-inner-spin-button auf height:auto setzen soll. Das hatte bei mir keinen Effekt.

Onkel Claude meint nur "isso" und empfieht das Entfernen der Spinner mit entsprechenden appearance-Werten. Oder manuelle Korrekturoffsets für Chrome (was dann bedeuten würde, dass ich Chrome als Client erkennen müsste oder einen "fix this" Schalter bräuchte - argh!)

Nach etwas Diskussion mit dem Kameraden kamen wir auf

@supports selector(::-webkit-inner-spin-button) {
  input[type=number] {
    translate: 0 0.25em;
  }
}

was für Chrome und Safari greift (Safari habe den Fehler auch, sagt Claude) und das Problem scheinbar fixt. Die 0.25em scheinen auch mit font-family und font-size halbwegs brauchbar zu skalieren (ein paar Deko-Fonts passen nicht, aber das ist wohl irrelevant).

Ich habe dann noch etwas gebastelt. Der Textfield-Container für input type="number" ist in Chrome eine Flexbox, und damit bin ich auf

input[type="number"]::-webkit-textfield-decoration-container {
  position: relative;
  padding-right: 1ch;
}

input[type="number"]::-webkit-inner-spin-button {
  position: absolute;
  right: 0;
  height: 100%;
}

gekommen. Das halte ich für besser, weil absolut positionierte Elemente die Baseline nicht mehr beeinflussen.

Eine funktionierende CSS-Eigenschaft, die explizit die Baseline-Steuerung beeinflusst, habe ich nicht gefunden. Ich habe es mit baseline-source:first auf dem input und auf input::-webkit-textfield-decoration-container versucht, leider ohne Effekt.

Stimmt es, dass Safari das Problem auch hat?

Ich habe den position:absolute-Würgherum im Fiddle eingebaut. Ist das brauchbar? Oder gibt es andere Nachteile? Der Workaround scheint font-agnostisch zu sein und sollte auch dann funktionieren, wenn der Bug irgendwann gefixt wird.

Rolf