Danke für deine informative Antwort. Was ich aber immer noch nicht verstehe ist, wenn ich das input-Tag per CSS auf display: inline
setze, kann ich die Größe immer noch ändern.
Es gibt sogenannte
replaced elements und
non-replaced elements. Replaced elments werden von MDN folgendermaßen definiert:
In
CSS, a
replaced element is an element whose representation is outside the scope of CSS; they're external objects whose representation is independent of the CSS formatting model.
Ref
Ein Beispiel dafür sind
<img>
tags. Ein Bild ist ja kein Text, der zwischen dem opening und closing tag stehen. Stattdessen wird bereits in der Vorbereitungsphase beim Laden der Seite der Content durch das Bild im
src
tag
ersetzt. CSS unterstützt dich dann beim positioning und scaling des Elements, du kannst allerdings nicht
das Bild selbst verändern, also z.B. Pixel austauschen oder so. Auch mit Filtern veränderst du den Content des Bildes selbst nicht.
Non-replaced elements sind genau das, was der Name aussagt: Nicht ersetzte Elemente. Das sind z.B.
<p>
oder
<div>
tags. Wie ihr Content gerendert wird, ist von CSS abhängig.
Was ist dann ein
<input>
? Es gibt eine Außnahme was
<input type="image">
betrifft:
HTML spec also says that an
<input>
element can be replaced, because
<input>
elements of the "image" type are replaced elements similar to
<img>
.
Ref
Alle anderen (wie
type="text"
) sind
inline, non-replaced elements.
Die W3C-Recommendation besagt, dass die
width
property auf folgende Elemente zutrifft:
All elements but
non-replaced inline elements, table rows, and row groups
Ref
Dementsprechend müsste auf
<input type="text">
die
width
property nicht zutreffen.
Für einige Elemente gibt es Ausnahmen (Beispiel Buttons):
Otherwise, if the computed value of
'display' is a value such that the
outer display type is '
inline', then behave as '
inline-block'.
Ref
Leider konnte ich eine solche Ausnahme in den
HTML-Specs nicht finden. Das fällt also auch raus.
Bis jetzt deutet also nichts darauf hin, dass hier irgendeine Regel es erlauben würde, inputs mit CSS zu manipulieren, sodass
width
,
height
, etc. geändert werden könnten.
Die Erklärung, warum inline non-replaced elements (eigentlich) nicht verändert werden können, erklärt die W3 folgendermaßen:
The content width of a non-replaced inline element's boxes is that of the rendered content within them (
before any relative offset of children). Recall that inline boxes flow into
line boxes. The width of line boxes is given by the their
containing block, but may be shorted by the presence of
floats.
Ref
Kurzform: Der Inhalt von Inline-Elementen befindet sich in line boxes. Die Breite einer line box kann nicht direkt gesteuert werden. Es wird ausschließlich vom umschließenden Block und floats bestimmt.
Wenn dem aber, z.B. bei Buttons, Folge geleistet werden würde (also Buttons tatsächlig als
display: inline
gerendert werden würde), dann würde der Content verschoben sein.
Ref
Warum also verhält sich der Button anders? Buttons sind sogenannte
atomic inline-level boxes, die sich wie folgt verhalten:
The box is a singular, solid unit, and that it cannot be split across lines like an inline box can when its text cannot all fit on a single line.
[...]
If there is no longer any space on a line to fit an atomic inline box,
the entire box wraps to the next line if there is a line break opportunity (otherwise it overflows the line box), even if the atomic inline box contains inline content that would partially fit the remaining space on the current line. This is because the inline content of an atomic inline doesn't participate in the same inline formatting context as the atomic inline itself — it participates in a separate inline formatting context
within the atomic inline box, and therefore must remain within the boundaries of the atomic inline box.
Ref
Das Resultat ist, dass Elemente auf einmal wie
inline-block
Elemente behandelt werden (siehe
Beispiel).
In einem (leicht abgeänderten)
JSFiddle siehst du das Verhalten. Obwohl der Button auf
inline
gesetzt ist, wird er als Block dargestellt, eben aufgrund dieser atomic inline box.
Denselben Effekt zeigen
input
s, wie sich an diesem
JSFiddle erkennen lässt. Ein
input
wird ja nicht auf einmal Mehrzeilig, wie eine
textarea
, sondern Einzeilig. Wie bereits in der Definition beschrieben, overflowed der
input
die Box, da sich keine wrap Möglichkeit anbietet.
Meine Vermutung ist, dass
input
s ebenfalls atomic inline-level boxes erzeugen, welche ja wie
display: inline-block
behandelt werden (siehe
Beispiel).
Aber es ist wie gesagt nur eine Vermutung. Ich hoffe allerdings, dass diese der Wahrheit entspricht und ich dir meinen Ansatz und meinen Gedankengang relativ verständlich erklärt habe.